First iPhone Post

Posted on August 2, 2008
Filed Under Cocoa, iPhone | Leave a Comment

This is my first post from an iPhone and I must say the software is pretty straight forward. I assumed I would have to set my server up for email posting but that’s not the case. It just works. Crazy huh?

Anyways, this post is more about the iPhone than just it being written with on. I’m going against what my last post mentioned regarding things to come… at least for now. Instead of posting about iPhone graphics and Ajax, I will be writing posts about an upcoming app for the iPhone that I will be writing in the coming weeks, ColorPicker. It will be an app that will allow web developers to easily find the hex values for colors. Initially, the app will show a color palette for the user to chose from by panning and zooming around it. The user will also be able to discover the hex values from photos in their albums as well as ones take with the app directly. Currently, the Tshirt I’m wearing is #ffffff. Well techically it’s #eeeeee… I don’t use bleach.

Expect more on this soon. Btw, red robin makes for a great place to blog from.

Things to Come: iPhone Graphics and Bundled AJAX Requests

Posted on June 21, 2008
Filed Under AJAX, Cocoa, JavaScript, PHP, Things to Come | Leave a Comment

There are a few things in my pipeline that I’m working on and should have posted shortly. Here’s a quick look at what I have in store for the next few posts:

iPhone Graphics

The iPhone OS is based on the same foundation as Mac OS X and it can be seen straight through to the SDK that’s going to unleash hundreds of quality applications to the platform in coming weeks. Since the iPhone is a completely new product, it gives Apple a great opportunity to test out new ideas from user-end features such as Multi-Touch all the way down to the way to draw graphics to the screen. One area that I will explore is the differences between drawing graphics in Mac OS X and the iPhone.

Bundled AJAX Requests

Recently, I finished my series on my PHP AJAX Framework. Like many software projects, it is work in progress and will continue to be until it is absolutely perfect (aka never). In my spare time, I have been thinking of different scenarios where multiple requests made sequentially could be unnecessarily queued up when instead they could be sent as a single request. This is fairly easy because of some assumptions we can make about what the developer and user should be expecting when they make these requests. I will talk about the thought process that went into the addition and post a code update.

Event-Based AJAX Framework for PHP : Part 5

Posted on June 8, 2008
Filed Under AJAX, JavaScript, PHP | Leave a Comment

Articles in this series:

1. Introduction to the Framework
2. Problems with Creating an Event Based AJAX Callback Mechanism
3. JSON data passing
4. The Scriptifiable Interface
5. The Remotable Interface

This is the fifth and final part to the PHP AJAX Framework series. In this article, I will explain how to use the Remotable interface and why it was created in the first place.

What’s it for?

In order to use the framework, the classes you create that you would like to call remotely must implement the Remotable interface. Any static methods you create in this class will be accessible from client-side javascript via the framework.

When implementing the Remotable interface, your class must include two methods: PreJsonDecodingJavaScript and PostJsonDecodingJavaScript. They must return strings of JavaScript, but those strings can be empty if you don’t wish to use that functionality.

Why bother?

You might ask, if the implemented interface methods can return empty strings why do I need to do this in the first place? Well the idea of this interface lies more in security than in the functions themselves. By creating this restriction, this framework is guaranteeing that client-side script will not be able to call static methods from classes that do not implement the Remotable interface.

That’s basically it. I hope you enjoyed the series and if you have any further questions about the framework, drop me a note.

Get the Source

Download the PHP-AJAX Framework

Event-Based AJAX Framework for PHP : Part 4

Posted on June 4, 2008
Filed Under AJAX, JavaScript, PHP | Leave a Comment

Articles in this series:

1. Introduction to the Framework
2. Problems with Creating an Event Based AJAX Callback Mechanism
3. JSON data passing
4. The Scriptifiable Interface
5. The Remotable Interface

This is the fourth part to the PHP AJAX Framework series. In this article, I will explain how you can take the built-in JSON encoding one step further by implementing the Scriptifiable interface.

Isn’t JSON enough?

JSON is great. It’s simple and elegant. It lets you pass data back and forth from the server in a way that is easily parsed, but in the end, it’s just a data structure. There is no functionality that you can leverage outside of key:value pairs. The Scriptifiable interface attempts to address this issue by providing a structure for adding JavaScript to your PHP file that will be added to your parsed JSON object allowing you to keep all of your object code in one file for both PHP and JavaScript.

How do I implement it?

Just like implementing any interface, we start off by creating a class. Below is an example of a class (TestClass) implementing an interface (TestInterface):

 class TestClass implements TestInterface {

}

That’s it. All an interface is is a contract that the class that implements it promises to abide by. If the interface says there will be a method foo that returns a value of type bar, the implementing class must provide that method; even if it doesn’t do anything. The Scriptifiable interface is very straight forward and only requires one method: GetScriptClassMethods.

Since PHP is a weakly typed language (and one that doesn’t really offer much as far as type hinting either – though that’s getting better), the interface can’t require that GetScriptClassMethods returns a string, but that’s the idea. GetSCriptClassMethods must return a string that contains the JavaScript that will be added to the client-side class.

If your client performs a RemoteInvoke on TestClass::ServerSideFunction and that function returns a value of type ReturnClass, JSON is used to first get all public properties in ReturnClass and generate a JavaScript equivalent. After that is done, a method called populate is added to the client side version of the returned object. The populate method contains the string returned from GetScriptClassMethods and it is called when the server returns the value to the client (on page load).

Here’s an example of GetScriptClassMethods:

public static function GetScriptClassMethods() {

   return <<<JSCODE
   this.tellAStory = function() {

      alert("what is your problem. " + this.value);
   }
JSCODE;
}

The <<<JSCODE   JSCODE; is just a way of writing strings in PHP called heredoc. Heredoc does parse values (like this.value above) unlike nowdoc.

Get the Source

Download the PHP-AJAX Framework

What’s next?

In the next article in this series, I will discuss the last component to this Framework: the Remotable interface. With this, you will be able to designate which classes have static methods available for Remote Invocation, providing a simple level of protection from attack. (Don’t rely on this one, though.)

Event-Based AJAX Framework for PHP : Part 3

Posted on June 1, 2008
Filed Under AJAX, JavaScript, PHP | Leave a Comment

Articles in this series:

1. Introduction to the Framework
2. Problems with Creating an Event Based AJAX Callback Mechanism
3. JSON data passing
4. The Scriptifiable Interface
5. The Remotable Interface

This is the third part to the PHP AJAX Framework series. In this article I will talk about how JSON was used in this Framework to pass complex data structures between the client and the server.

What is JSON?

JSON is a format developed by Douglas Crockford of Yahoo. The acronym is short for JavaScript Object Notation. The format is fairly simple and involves string : value pairs or basic ordered list of values. JSON does not allow you to pass methods between the client and the server (that would be hard), but this Framework provides a workaround for that scenario by having your PHP class implement the Scriptifiable interface. I’ll get to that later.

Client to Server

In the last article in this series, I talked about how the RemoteInvoke method worked and explained how you pass parameters to your server-side function in an array. What I didn’t mention is that each of those parameters are stringified to JSON before they are passed to the server. This is critical because it opens the types of parameters you can pass to custom javascript objects. If your server-side function needs all the information that’s contained in your JavaScript class to do the necessary processing, instead of passing each value individually, just pass the object itself. Then, on the PHP side, Remotee.php json_decode’s each parameter and passes them into the called function.

Server to Client

The same goes for return values. When your PHP is done executing, the return value is json_encoded on the server and then parsed on the client into a JavaScript object.

Get the Source

Download the PHP-AJAX Framework

What’s next?

In the next article in this series, I’ll explain how to take this one step further and not only return the member variables of your PHP classes, but methods as well by implementing the Scriptifiable interface.

Event-Based AJAX Framework for PHP : Part 2

Posted on May 29, 2008
Filed Under AJAX, JavaScript, PHP | 7 Comments

Articles in this series:

1. Introduction to the Framework
2. Problems with Creating an Event Based AJAX Callback Mechanism
3. JSON data passing
4. The Scriptifiable Interface
5. The Remotable Interface

This is the second part to the PHP AJAX Framework series. In this article I will discuss the problems involved in creating an event-based ajax callback mechanism and how to get around them. 

The biggest issue with creating a versitile event based AJAX callback system is figuring out how to return executable script back from the server. There are a few ways to do that, but what I feel is the easiest of them (and the one I used in creating this framework) is the iFrame-AJAX method.

To perform an AJAX call with an iFrame, you start off by putting a 0px by 0px iframe on your page. Just to be sure no one can see it, I set the visibility CSS property to hidden. After that’s in place, you can have a javascript function available to update the src tag of your iFrame, forcing it to reload.

The big difference between this and an XMLHttpRequest call is that this forces the browser to parse and run any javascript returned to that hidden iFrame. This is crucial because any script you add to your iFrame’s onload event will fire once the content is loaded. This essentially means that all processing on the server is completed and you can notify your user that something has happened (or if an error occurred in the process).

Here’s how you might implement iFrame AJAX:

Inside the Remoter JavaScript Class

At start up, this client-side class needs to set up the iFrame that it will use to communicate with the server. I haven’t figured out another way to do this yet, but in order for the script running in the iFrame to know what the variable is for the Remoter instance, I chose to pass this in as a string on construction.

After that is all set, we can make calls to it using the RemoteInvoke method. This method takes in 4 parameters: the Remotable PHP Class name, the static function in that PHP class that you are calling, an array of parameters, and a reference to the javascript callback function.

The Remotable PHP Class

For now, we’ll just assume all classes fall into this category. By convention, we’re assuming your classes have file names that follow this pattern: ClassName.class.php. You will pass “ClassName” as a string into the first parameter space of your RemoteInvoke call.

The Static PHP Function

This is just a static method in the Remotable PHP class. Nothing special. Just like your ClassName parameter, you’ll pass this in as a string to your RemoteInvoke call.

Array of Parameters

You can pass this in either as a variable pointing to a new Array(params, go, here) or to just put new Array(params, go, here) right in the function call.

Javascript CallBack Function

This function will be called immediately after the server-side code has completed executing and the results are returned. The callback function will be called with your return value as an argument, if there is one. The return value will be null otherwise.

Making the Call

To make the AJAX call, Remoter needs to formulate a query string that is comprised of all the stuff needed to execute the call on the server side. The query string is passed to a PHP file called Remotee.php that gets loaded in the iFrame after being processed, and in the end, executes the callback. Below is a remoter.RemoteInvoke function call and the resulting string that the iFrame’s src is set to:

The RemoteInvoke Call

remoter1.RemoteInvoke(”MathClass”, 
                     “AddFunction”, 
                     new Array(1, 2), 
                     function(result) {
                        alert(result); 
                     });

The Resulting iFrame src Tag

 iframe.src = "remotee.php?rand=0.393858&remoter=remoter1&params[]=1&params[]=2&class=MathClass&call=AddFunction";

We pass the params in as an array of values, the class and function call make sense, but what is the rand for?

Rand

There’s always a chance, when dealing with iFrames (these are just web pages), that your browser will cache and redisplay content if it thinks it doesn’t need to re-get it. To trick your browser into always thinking the content is new, we get a random number and throw it in the query string. It is reasonable to say that this makes the iFrame src tag unique always.

What is Remotee.php

The Remotee script does the following:

1. Get the desired PHP class.
2. Call the requested function in that class.
3. Return an HTML page that, onload, executes the CallBack function with the return value as its parameter.

Nothing incredibly special here.

Get the Source

I’m including the entire source in this article. If improvements are made between now and the time the series is finished, it will be updated accordingly. I will also link to it in subsequent postings. If you have any questions about what was covered in this post, please feel free to ask. If you have questions about pieces of the framework that were not yet covered, drop me a note and I’ll make sure they get answered.

Download the PHP-AJAX Framework

What’s next?

The next post in this series will cover how we use JSON to pass more complex data structures from PHP to JavaScript and JavaScript back to PHP.

Event-Based AJAX Framework for PHP

Posted on May 18, 2008
Filed Under AJAX | 7 Comments

Articles in this series:

1. Introduction to the Framework
2. Problems with Creating an Event Based AJAX Callback Mechanism
3. JSON data passing
4. The Scriptifiable Interface
5. The Remotable Interface

This is the first in a series posts on developing an event-based AJAX framework for PHP. There are plenty of AJAX frameworks out there but this one has a few things going for it that others might not:

1. Call static functions in any PHP class file that implements the Remotable interface.
2. Return javascript representations of PHP objects (with executable javascript functions). Just implement the Scriptifiable interface.
3. Don’t worry about stepping on your individual calls. They’re queued automatically and called in FIFO order.

Here’s a quick look at the client side script involved in making a call.

var CallBack = function(returnValue) {
alert(returnValue);
}


var remoter = new Remoter("remoter");
remoter.RemoteInvoke("RemotableClass", "staticFunctionInThatClass", new Array("param1", "param2"), CallBack);

Pretty straight forward. What’s nice is that the returnValue can also be a PHP object which, by the time it gets to your callback, has been turned into a JavaScript object courtesy of JSON. What’s even better is that if that PHP class implements Scriptifiable, the returnValue will also include any functions you specify.

That was just an intro. Check back soon for the second part to this series where we tackle the first part to this problem: Returning Executable JavaScript from an AJAX Call using iFrames.

Tip-toeing in Objective-C: A first look at the syntax and seeing its true beauty.

Posted on April 4, 2008
Filed Under Cocoa | 4 Comments

I’m beginning to learn Objective-C in my spare time and its syntax is something that’s taking me surprisingly long to get used to. I understand the concepts sufficiently well and they map to ones that you’ll find in most other languages. But, again, the syntax is… different.

I’ve never written any Smalltalk before, which is a language with a syntax that Objective-C was heavily influenced by, but I have written plenty of Java and now spend most of my time writing C# in .NETland. The Cocoa I mentioned in the title of this article is essentially to Objective-C what .NET is to C#, a bunch of free goodies. I’m sure I’ll get into that in a future post, but for now, I want to talk about the basics (being that that is all I know at the moment).

Objective-C is an object oriented language like PHP, C#, Java, etc so passing around chunks of data along with their functionality is very easy. So, let’s start from the top.

Let’s say we have a class. We’ll call it Dog. All dogs can bark, they have a name, they have a hair color, and maybe even a personality. We can encapsulate all of this information about how we describe a dog and what a dog can do in a class.

In PHP, the dog class would look something like this:

class Dog {
  var name;
  var personality;
  var hairColor; 

  __construct($name) {}

  public function bark($volume) {
  if($volume == "loud")
       echo "'WOOF!,' said " . $this->name;
  else
  echo "'Yip,' said " . $this->name;
  }
}

To keep things super simple, I left out privatization of variables and any mutators. If you don’t know what those are, it’s not important at all yet, so don’t worry. The important thing is that you understand that all the information about a dog is stored in this thing we’re going to call a class.

Here’s some simple code that uses it:

 $myDog = new Dog("Zoey");

 $myDog->bark("loud");    // prints out "'WOOF!,' said Zoey.";

First, I constructed an instance of the Dog class creating a Dog object referenced by the variable $myDog. I can then set the member variable, $name, using the ->. After setting the properties of the Dog object, you can then retrieve them. You can also make Zoey bark by telling her to with $myDog->bark(). It’s that easy.

Now, you have entered the twilight zone…… doo do doo do… yeah, well. Now, we’ll do the same thing in Cocoa and compare them. In Objective-C, like C++ and other languages, a class is made up of two files: an interface (.h) and an implementation (.m).

This is the interface:

@interface Dog : NSObject
{
  NSString name;
  NSString personality;
  NSString hairColor;
}
- (void)barkAtThisVolume:(NSString)volume;
@end

This is the implementation:

@implementation Dog
- (id)initWithName:(NSString)dogName {
   name = dogName;
}

 

- (void)barkAtThisVolume:(NSString)volume {
  if(volume.equals(@"loud"))
    Console.Log("'WOOF!,' said " + name);
  else
    Console.Log("'Yip,' said " + name);
}
@end

To get things started, I must mention the obvious; PHP is a very simple language and has many limitations. There are no object libraries written by the people who make PHP. There are third party ones like Pear, et al, but nothing written by the lovely people at PHP.net. Maybe that’ll be coming in the future though, because even classes in general were not supported until just a few short years ago. That said, you will notice things in Objective-C that you simply wont find in PHP. Granted, I am referring to things in the Cocoa Framework, which like I said before, is to Objective-C what .NET is to C# (or Pear is to PHP). The difference between Cocoa or C# and Pear is that Pear is written by a third party and Cocoa is written by the primary contributor/creator of Objective-C, Apple. Same goes for C# and .NET, whose creator is the gigantor – Microsoft. The point that I’m getting at is you probably read NSObject and thought, wtf?

NSObject is the root class of most Objective-C class hierarchies. Basically, by inheriting NSObject, you get the core functionality that you should expect when using the Cocoa framework. So, after all that, we sort of didn’t need NSObject, but now I wrote that last paragraph and I’m not about to go and delete it.

The interface is where you define your member variables and your method signatures. The implementation is where you actually use it all and do the heavy lifting. Here is the same code we used above in PHP, in Objective-C:

Dog myDog = [[Dog alloc] initWithName:@"Zoey"];

[myDog barkAtThisVolume:@"loud"];

Constructing a PHP object happens with the new operator. In Objective-C, this happens with alloc. In PHP, we create a function called __construct and call it using the name of the class, Dog( ). In Objective-C, we call a function conventionally prefixed with init. Now, this next part is where Objective-C really shines. I’m not sure if you noticed it right away, so let’s put the PHP call to bark next to Objective-C’s.

PHP
$myDog->bark("loud");

Objective-C
[myDog barkAtThisVolume:@"loud"];

What do you not know when you read the PHP code, that you know right away when reading the Objective-C? You know exactly what “loud” means. There’s no question because Objective-C has named parameters. A named parameter puts exactly what a variable is supposed to be about directly in the signature. Let’s look at something a little more complicated and you’ll really start to know the difference. I’m not going to define the classes, but will expect you to imagine what they would look like.

Imagine if our dog class had a method that took your dog for a walk. I want to make this overly complicated to show a point, so it will take in parameters for different things. I’m not going to tell you what they are… again to prove a point, so read the code below, think about it really hard, and then read on.

PHP
$myDog->walk("20", "30", true);

 

Objective-C
[myDog walkDogaDistanceInMilesOf:@"20" OrForADurationInMinutes:@"30" StopToPlayAtThePark:YES];

First off, give me a break if you don’t like my parameter names. I think it goes to show what I mean, though. In PHP, you have no clue what the parameters mean unless you comment your code. Objective-C is almost completely self-documenting. Each line of code completely explains what should come in and what should be expected as output. While it definitely helps when you create human-readable variables and comment where necessary, Objective-C makes this a whole lot easier to do.

After I learn more of the Cocoa Framework, I’ll be writing again with more useful code. I suppose our Dog class will have to get you by until then.

[Update] I honestly forgot to post what the parameters were after I wrote the Cocoa! Maybe that means, we should start documenting PHP, C#, etc with Objective-C! How lovely.

First Post, Take Two

Posted on March 30, 2008
Filed Under Uncategorized | Leave a Comment

I posted my first article to this blog a few weeks ago. I was determined to put all of my content in a single blog and then republish certain articles to my company blog as it seemed fit. Well, after a lot of work, I determined that that wasn’t the best way to do things. Maybe it was fate… because the blog software we use for the company didn’t seem to want to let me do it my way anyways. The options for republishing a feed wouldn’t work, so this is where it leaves us. Two blogs for two purposes. It makes more sense this way.

In my company blog, I’ll post about Build Systems and Web technology from the perspective of a .NET developer. Here, I can explore those same topics and others from the perspective of a Mac user and a person who likes to tinker.

Recent events have pushed me to start learning Cocoa (I heard some company released a phone 9 months ago or something). While that’s slow going, I think you’ll see some code snippets posted here as soon as the NDA allows me to. I also write quite a bit of PHP code. While I’m definitely becoming more and more spoiled by the .NET that’s behind ASP, PHP still holds a place in my heart and I’m sure I will continue to develop for it. I just find that much of my PHP work is in making it sometimes emulate what I get for free in .NET (or Java, etc).

Well, here’s to take two of this blog. I’m sure you’ll enjoy this as much as I will.

P.S. I’m currently trying to find a good captcha plugin for this site. I’m installing GD Library soon, so that should increase the number of options I have. I’ve tried a few captcha plugins without much luck. I’m not really interested in signing up with a third party site to generate the images, so my next attempt will be with Captcha!.

Wish me luck!

« go back

• Recently Written

  • Why Safari’s “Clear Recent Searches” is Gone
  • Appleville, North Carolina: A Better Place [for iPhone Push Apps] to Be
  • White is Not the New Black for Apple
  • Really Google? Why might all sites (including your own) harm my computer?
  • Safari gets Anti Phishing Tech and I didn’t even notice
  • Bank of America Site Finally iPhone-ified
  • Using ecto Blogging Software for Mac with Community Server
  • Checklist iPhone App
  • PC Rescue
  • Matt Damon on Palin

• Categories

  • AJAX
  • Cocoa
  • iPhone
  • JavaScript
  • PHP
  • Review
  • Things to Come
  • Uncategorized

• Archives

  • September 2009
  • July 2009
  • January 2009
  • December 2008
  • September 2008
  • August 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008

• Blogroll

  • My Atalasoft Blog

• About

  I am a software engineer at a Document Imaging toolkit developer, Atalasoft, located in Easthampton, MA, where I work with a team of developers building a SharePoint Document Viewer called Vizit. I develop for the web and other platforms using .NET, ASP.NET, PHP, SQL of various flavors, and JavaScript (AJAX).

• Search

• Admin

  • Log in
  • Wordpress
  • XHTML