Cory Wiles Blog

In one of my previous blogs, I wrote about my desire to move forward with converting my site to HTML5 and CSS3.  Obviously I can't make a FULL transition due to browser backward compatibility, time, and what is supported with newer browsers. However, the longest journey begins with a single step.  My first step in this transition is to replace the top image header, with a pure CSS3 solution.  Having the ability to apply gradients with CSS3 I was able to completely remove that banner image with just a few lines.

Lately in the PHP/Zend Framework blog world there has been much discussion concerning what constitutes a model in an MVC app.  In the current implementation of the MVC apps at work our ZF Form implementations are processed in a corresponding model class as well as a 'notify' method which handles emailing a response after successful submission.  I was able to abstract all aspects of the email properties except for the message body.

Most of the time the requirement is to have, basically, the same form view but with the values populate.  That usually means creating some long and kludgy looking heredoc or worse a huge string of crazy html intermingled with escapes.  Neither solution was very appealing to me.  I kept thinking more and more that the email body was really a view.  So I treated as such.  So my solution was to create a global views directory and a view script that was the email body template and passed it's render method to Zend_Mail instance.

This allows for further separation of models and views.  I know that technically the email body should be apart of the model, but far too many times I have to change how the body of the mail looks, not the data, so it lends itself to more of a view.

Please feel free to comment.

::NOTE::
Forms as model architecture taken from http://weierophinney.net/matthew/archives/200-Using-Zend_Form-in-Your-Models.html

I was presented with a project where the client wanted a form that would accept credit card payments via paypal.  I could either write it in PHP or Java. While I am a big fan of both languages I felt in this instance that PHP was the most time efficient route.   However, PayPal doesn't offer an API for PHP. Only Java and .NET.  As to not be discouraged I decided to spend a little time trying to come with a custom validator that would handle the validation of the credit card validation.

::Warning::
My use case was very specific.  I only needed to authorize credit card sales.  Basically their simpliest form of transations.

Since all the applications that I write now are us the Zend Framework I was able to reduce "inline-code" by creating a custom validator that I assign to my preValidation method inside of the model.  :: I worked on this concept with Jeremy Kendall ::

There is definitely room for improvement, but this is might be helpful to others.  For example, the paypal options should really not be declared as Zend_Config instance, but checked for an instance of Zend_config and then set as an array with the toArray method.

// Validator

One of the many growing requirements that I am experiencing at work is for internalization of our forms.  In this particular use case the languages available are limited to English and Spanish so I am not able to use Zend_Locale::BROWSER exclusively.  To make sure that correct form displays, in my form model class I created an array of allowed locales.  Before the form instantiated in the controller the language param is set the registry, and then that locale is checked against allowed locales.

References:

• Zend_Locale
• Zend_Translate

Translations - located in my models directory: Models/Languages/En.php and Es.php

If locale is allowed then the form label translation is set.

My wife, Erin, is doing some marketing work for KTF Consultanting.  Part of the overall marketing plan was to make some small changes to his website.  Being the samurai developer that I am, she recruited me for those "small changes".  I was happy to help.  I looked over what she wanted, which amounted to adding in his blog feed, add a few UI elements, and a graphic here and there.  Based upon the number of pages and simplicity of the site I assumed that the original developer just stuck with static HTML or maybe PHP to utilize includes.

I was wrong.  The site is actually powered by MODx.  What I thought was going to take me a few hours just took a completely different turn.  I wasn't too worried considering I have worked with a wide variety of CMS' in the past. I was pretty confident that if MODx was worth it's salt then I should be able to knock out what I had to.  In the end I was right.  Though MODx wouldn't be my first choice for a CMS it certainly has it's strengths and I would recommend it to any one as an option.  Creating/editing the content was easy and I didn't even have to consult their documentation.  Granted I didn't go through the install process, but if I did reference that in the documentation out of curiosity and it didn't seem too complicated.

One of only frustrations that I had is how MODx treats their templates.  In this particular instance, the template/theme was stored in the database.  In order to edit the template I had to login to the management console and edit the template inside of a large textarea.  I was very confused when I first saw this because I couldn't tell if the developers of MODx where trying to treat the template as a model or had some other "geek reason".   Almost immediately after tweeting about my confusion I received a response back from one of their community developers who stated:

"The template is a view structure. There is nothing about MVC that requires views be stored in the FS. You can have templates in FS. Templates can be considered a managed content type as can documents that can also be used for views too.  MODx templates are a data record which doesn't make it part of a model. It is referenced via controller just as a FS record.  I understand that you prefer to have your templates on the FS. MODx won't limit you to db based templates."  @jaygilmore

While his statement is correct, there is NOTHING in MVC that requires views to be stored on the file system, using the database to store the template isn't practical.  You can steer your car while driving with your feet, but it doesn't make it a good idea.  There are a few fundamental issues that I had with keeping your templates in the database.  What happens if the database crashes.  I am sure that the templates are cached on the file system, so that each request for a page doesn't require a call the database, but if/when that cache expires then your site is HOSED.  In addition, if indeed the template is cached on the file system then why even bother with keeping it in the database.  Bypass that all together and keep all views/templates on the file system.  Finally, there is the creation/maintenance of the views/templates issue.  In most scenarios that I have worked in either with a company or freelance the template/design side of the site is usually handled by a designer...as it should be.  Designers shouldn't, and most don't know how to, edit/create templates from the database or backend management system.  They want to be able to, wait for it...create/edit on the file system.  That is what is intuitive and the most efficient.

I will summarize by saying that I did read where you can keep your templates on the file system with MODx, but unfortunately it is not straightforward and what I can tell not what is encouraged.  If there is better documentation out there on the subject then please let me know.  Overall, I really liked working with MODx.  There are many aspects that it does very well and they far outweigh those that they don't.  No CMS is going to do everything that you want.  Most get you 80% of the way there and it is up to the samurias of the internet knock out that remaining 20%.

MODx CMS Hompage: http://modxcms.com/

It is forgone conclusion that if you need to present a large amount of data with a UITableView then you should do so using an index and index sections.  As with most tutorials that I have read on this topic, the scenarios used got me 80% of the way.  In my humble opinion, the solutions where either over engineered or they didn't apply to my use case.  Hopefully this tutorial/sample project will bridge the gap.

The tutorial that I got the most from is: iPhone Development: Creating Native Contacts like screen.

One of the biggest hurdles that I had to over come, that was different from the contacts tutorial, was that I wasn't using a database and therefore didn't have a predefined sub-result set for each character.  I was having to do the opposite.  I had to iterate over my result set, array of states, grab the first letter from each item, check to see if there was already a dictionary key that existed for that letter and proceed accordingly.

Logic Flow
Iterate over states
Get the first letter of that particular state
Check to see if there is a key in the objectsForCharacter dictionary
   - YES: add the state string to the arrayOfNames array and then set the arrayOfNames to the objectsForCharacter dictionary for the appropriate key
  -  NO: remove all objects from the arrayOfNames array and add the firstLetter to the arrayOfCharacters.  Then proceed on to the above "YES" steps
Once all the states have been "proceed" then reload the table data

Final Model
Though it sounds some what complicated with all the arrays, dictionarys, etc. once you break it down to a visual model then the code is easier to comprehend.

[[objectsForCharacters objectForKey:@"A"] objectAtIndex:0]; // Alabama
[[objectsForCharacters objectForKey:@"A"] objectAtIndex:1]; // Alaska
[[objectsForCharacters objectForKey:@"A"] objectAtIndex:2]; // Arizona
[[objectsForCharacters objectForKey:@"A"] objectAtIndex:3]; // Arkansas

Download Example Project (comments/enhancements are welcomed)
IndexedTable.zip

Not My Idea
Erin always asks me if I use one-third of the apps on my iPhone.  Truthfully I don't.  There are probably four apps that I use 80% of the time. The others I download or purchase because they inspire me. I might like the way that the app is designed or handles a particular usability feature or the combination.  Then there are the few that I downloaded because my daughter REALLY likes them.

The three or four ideas that I had for my first "App Store" app where good, but they would take quite a bit of time to develop and I was looking for a project that would be  straightforward that people could use and that I could turn around in about two or three months working on it part-time.  My wife came up with a fun concept of having an app that would allow a user to "erase" their ex from their phone.  Immediately, I thought this was a great idea and  the brainstorming began.

Early Stages
As a developer I knew what I wanted to put into the app, as far as, functionality goes, but I really wanted my wife's thoughts/opinions/feedback since she:

1. Came up with the idea
2. Is in sales/marketing and knows "people" better than myself

In the beginning she started the conversation with, "Can the phone do this?".  I stopped that immediately because I wanted to hear what she envisioned as the perfect break-up app.  After getting a list of all the "wants" we sat down together again to go through them and make our first round of cuts which basically amounted to me explaining that the phone didn't have that functionality.  Over the next few days we came together again and made a list of three or four major features that needed to be included with some "nice-to-haves" added at the end.  Let the coding fury begin.

Hard Decisions
As I started down the path of coding the app things went VERY smoothly and I was quite happy with my progress and my continued growth of knowledge of not only Objective-C/CocoaTouch, but mobile usability as well.  When I got about three-fourths of the way done with the project I hit a fork in the road.  I came up with a handful of features that I thought would be GREAT to add into the application, but would extend the project at least 4 weeks.  The features included various Facebook integrations, a "breakup/erase wall", video recordings (for those 3GS users), canned messages, top 10 breakup songs from iTunes, etc.  However, I had to make the tough decision to keep the current feature list and mark it as version 1.0 and save the others for future releases.   I am working currently working on version 2.0.

What Made the Cut?
The simplicity of the app is what, IMHO, makes the app pretty good.  I decided to keep, what I considered, core functionality.  The ability to send a photo and/or an audio recording and/or a written message via email.  I did add in the persistence level of the data and the ability to create multiple audio files, as well as, manage those files.

In Apple's Hands
Finally, after months of development, in the wee hours before work and after my daughter went to bed, I incorporated the custom UI elements, create a product site, and submitted EraseUrX to the App Store.  Fingers crossed.

Release
Seventy-two hours later, I got an email from Apple saying that app had been approved and was for sale in the App Store.  Like a kid at Christmas I couldn't click on the link fast enough.  To my dismay I got the equivalent of a 404 error.  I wish they would have had a little note in the email saying that it might take up to X amount of hours for the app to propagate to all their servers.  None the less by the afternoon it was there.  I had successfully planned, created, designed, and deployed an app to the App Store.

Hindsight
Looking at the complete process I do not have too many regrets.  The things that I would do differently are as follows, and in no particular order:

1. Start the marketing for the app earlier than right after I submitted the app.
2. I should have kept a development "diary" online that showed the progress and little teasers.
3. Had a promo video that went along with the app.  Not a technical video of what the app does, but a marketing video.
4. Done more research on successful, and maybe, unconventional ways of marketing the app.

What's Next
While I don't think that EraseUrX is a revolutionary app, I do think that it is decent, but like any creation it can, should and WILL be improved. There will be the option to either send the "breakup" via email or to Facebook, more fine grained control over what is saved on your phone for later review, video support, and a cleaner design.  As stated in my previous entry, the completion of this project has just fueled my desire to work more exclusively on iPhone apps.  Some will be personal projects, but for right now I'll concentrate on contract projects.  I am currently working with a local photographer to create an app to showcase the work that he does.  It is more than just another photo gallery slide show application and I think will have some nice additions to what people normally expect.

Stay tuned...

Based upon the myriad of tweets over the past three months or so, most who follow me know that I have been working on my first iPhone app.  Well, first to submitted to the app store.  I have finished an app for work and have started on another for www.feedfootball.com.  Though the app hasn't hit the stores YET, I already have the inspiration to build more.  EraseUrX has by far been the most rewarding project I have worked on in the past three years.  Even if I don't make a lot of money, it truly has been self satisfying to just complete this project.  I can't wait to get started on the next one not only for the challenges that await, but also I know that I be able to put it in the App Store faster.

There has been a lot of criticism of Apple's approval process in the App Store, but over the past three months they have made great strides to improve this process and it has benefited developers greatly.  In addition, there are rumors floating around of a possible upcoming announcement of the 4.0SDK and a new phone device, which if the 3.0 release is any indication of the amount new features added to the phone, then the 4.0 release will give developers even more tools to increase the usability and features in our apps.

Hopefully, the saying is true...

If you build it they will come.

I guess you could really argue that the "mobile revolution" was started when Apple first released the iPhone, but 2010, I predict, will be a year full of explosive new mobile technologies and adoption.  2009 saw a huge spike in the adoption of smart phones, as well as, the release of new platforms, devices, and applications.  For the past 10 years I have focused on desktop web apps, but am VERY excited about the breakthroughs and innovation that has evolved in the mobile arena, especially with the offerings coming from Google and of course Apple.  As a consequence, 80% of my focus will be on mobile applications, both native and web.

2008 was the year of "web 2.0", 2009 was consumed by social media, and I predict that 2010 will be a digital Magellan on steroids with the Location Based Services popping up everywhere.  Evidence of this is already presenting itself, with the purchase of GeoAPI from Twitter, Google is offering "turn-by-turn" directions for free in the latest Android SDK, and Apple purchased a map tile software company.  The question will be how will all this data and the services used to manage the data be best served for the consumer.  The days of showing pins on a map are growing quite old.  It is time for more forward thinking, which is what the before mentioned companies do best.

This is definitely a NEED not a want.

Being in a profession of constant change I am always reading someone's blog, tutorial or latest trends in various subsets of the web.  Most of the time I just fire up Google Reader and start reading.  However, over the past 6 months I have found myself using my iPhone as my "reader" of choice.  Partly because of the convenience factor and in addition, I don't have to carry my laptop around everywhere I go.  Outside of Google Reader one of the best sources that I have for great articles are from some of the big names in web development that I follow on Twitter.

However, the sites and articles that people are linking to are still optimized for a standard browser, not the mobile experience which is HIGHLY annoying.  It is not that I am too lazy to wait for the page to load, but the lack of patience that I have for the delay in the page to finish loading due to 30+ stylesheets requested, some ad tracking pixel or any number of other tasks that are processing that have ZERO to do with what I, the user, is trying to accomplish.  What I find myself doing more and more is using the mobile app functionality of emailing the link to myself so that I can read it when I do get back to my laptop.

Should this mean that companies should have a regular/mobile site?  There is no right or wrong answer for that.  You have to do research and look at your visitor trends and who your target audience is.  I would venture to say that if you are a news organization then the answer would be yes.  However, even though currently you might have a low percentage of mobile visitors that number will only increase over time and your site should at the bare minimum be optimized for a mobile browsing experience.