.…… got to do a post on the last day of the year. Happy new year everyone.

As might be expected a slew of frame­works are appear­ing that allow iPhone and other mobile plat­form devel­op­ment with­out nec­es­sar­ily need­ing to learn the very hard­core ele­ments of pro­gram­ming these devices, or that allow cross plat­form devel­op­ment or that enables cre­at­ing the appli­ca­tion as a web based ver­sion that mim­ics the actions of the native application.

I shall be doing some more in depth looks at these apps over a series of posts but ini­tially this post is to pull a num­ber of the more main­stream appli­ca­tions together.

The infor­ma­tion about the frame­works is pro­vided from the sites them­selves so may me taken as is.

Quick­Con­nect

Web Site

Quick­Con­nect is a pow­er­ful, mod­u­lar, sim­ple to use, appli­ca­tion devel­op­ment library avail­able for many lan­guages and plat­forms. Quick­Con­nect is cur­rently avail­able for: iPhone, Android & Mac JavaScript apps, Erlang/Yaws, and PHP.

IWe­bkit

Web Site

Iwe­bkit is the rev­o­lu­tion­nairy kit used to cre­ate high qual­ity iPhone and iPod touch web­sites in a few min­utes and is based on an LGPL license. In the first 4 months of it’s exis­tance the pack has greatly evolved from a basic idea to a project that has reached world­wide fame!

Phone­Gap

Web Site

Phone­Gap is an open source devel­op­ment tool for build­ing fast, easy mobile apps with JavaScript. If you’re a web devel­oper who wants to build mobile appli­ca­tions in HTML and JavaScript while still tak­ing advan­tage of the core fea­tures in the iPhone, Android and Black­berry SDKs, Phone­Gap is for you.

WebApp​.Net

Web Site

WebApp​.Net is a light weight, pow­er­ful javascript frame­work tak­ing advan­tage of AJAX tech­nol­ogy. It pro­vides a full set of ready to use com­po­nents to help you develop, quickly and eas­ily, advanced mobile web applications.

Uni­ver­sal iPhone UI Kit

Web Site

If you are look­ing a CSS frame­work to develop iPhone web appli­ca­tions you may check this project.

The UiUIKit (Uni­ver­sal iPhone UI Kit) it’s a col­lec­tion of HTML exam­ples of what can be done with CSS3 and Safari’s Webkit. With this frame­work you can:

Fast pro­to­type any web app with ease. Make you’re own app using difer­ent iPhone orig­i­nal interfaces.

The frame­work is based on 1 stylesheet and sev­eral HTML exam­ples, also, it con­tains orig­i­nal art­work so you can edit them in Adobe Pho­to­shop CS and adapt it to your projects. With this frame­work you can build:

jQTouch

Web Site

A jQuery plugin for mobile web development, optimized for the iPhone and iPod touch

I live approx­i­mately three miles from the cen­tre of Not­ting­ham and usu­ally can­not hear the bell chim­ing the hour in the town hall in the cen­tre of the city. How­ever today, with it being clar cold and frosty it is easy to hear. I sup­pose also the ambi­ent noise is lees as it’s sun­day and the fac­to­ries and traf­fic are less.

Usu­ally the only other time this occurs is in the sum­mer, in late evenings when it the air is clear and still.

Intro­duc­tion

Just some overview notes on the subject.

Which VCS?

There are many vcs’s around both free and paid for. The type of VCS while impor­tant is not as impor­tant as actu­ally using. From the sin­gle devel­oper up to big teams there is no way you should be cod­ing with­out a VCS.

There are cen­tralised sys­tems such as Sub­ver­sion where the project is held on a cen­tral server and devel­op­ers check out and in and deploy­ments are made from this cen­tral repository.

Then there are dis­trib­uted sys­tems, DVCS’s, such as Mer­cu­r­ial and GIT. With these the devel­oper has a local repos­i­tory, does all the devel­op­ment, check­ing in and out locally and when appro­pri­ate will push changes to another remote repos­i­tory to be merged.

See the end of this post for var­i­ous links

Some of the points to be kept in mind when using VCS’s

• A VCS does not replace com­mu­ni­ca­tion between mem­bers of a team
• Clear processes and guide­lines on how to use the sys­tem need to be in place, espe­cially when, as you inevitably will, break them to help recover gracefully.
• Read the book. SVN, GIT and Mer­cu­r­ial have books online that are free to read or down­load. They don’t have to be read from cover to cover and can be skimmed to get a feel for which is the right one for you.
• Before doing any­thing mod­er­ately com­plex take a backup of the repos­i­tory. That way you can blow it away and start again with­out shaft­ing your repository.

Branch­ing Merg­ing and Tagging

In SVN the prac­tice is to have three direc­to­ries, Trunk, Tags and Branch. For DVCS’s the con­ven­tions are some­what dif­fer­ent but I am going with the SVN nomen­cla­ture to sim­plify things.

• The trunk is always the ver­sion that you would go live with.
• Tags are one off snap­shots of the trunk and are not used for fur­ther development.
• Branches are for devel­op­ment work. A copy of the repo is taken and worked on. Dur­ing the life of the branch updates can be made from the Trunk if say bugs are fixed on the Trunk to keep the ver­sion in sync.
• At some point the Branch will be merged back into the Trunk, which will be fraught with pain and angst but at least you will have the tools and the abil­ity to see what you are doing roll back.
• Once this is done the branch is left but not used again and a new Branch made for the next level of development.

For DVCS’s the pic­ture is sim­i­lar as a process but dif­fer­ent in exe­cu­tion. Here the repos­i­to­ries can be cloned in total and worked on as a branch and then merged locally and then again merged with the remote/master repository

Deploy­ment

Devel­op­ment is done on local machines, checked out, worked on checked in or merged and then the deployed to the test envi­ron­ment (you do have a test envi­ron­ment don’t you?) and if it passes then deployed to the pro­duc­tion server. Ok that’s a sim­pli­fied ver­sion but some­thing along those lines.

• Rule 1 Do not deploy directly from the repository
• Rule 2 Do not deploy directly from the repository
• Rule 3 well you get the idea.

Deploy to a stag­ing area and then to move to the test server or the live server by using shell script­ing that will con­sol­i­date, add, edit, alter the files and then deploy them automatically.

rsync is a highly effec­tive way of mov­ing files from one server to another and has a plethora of options such as –delete which will remove files from the tar­get server that have been deleted in the repos­i­tory, there­fore keep­ing the server uncluttered.

exclude which can be pointed to a file will allow you to exclude file, say con­fig files which dif­fer between test and development

it is also pos­si­ble that all the assets are not in the repos­i­tory. Stor­ing assets such as images do not scale well in ver­sion con­trol sys­tems because these files are already binary, so a minor change can mean the whole file is altered and then stored in the VCS. This can add sig­nif­i­cantly to the repos­i­tory size which will reduce its effec­tive trans­fer speed.

The other major advan­tages of script­ing the build is the speed of deploy­ment, the fact that you will make far less mis­takes espe­cially when you need to deploy under pres­sure. It allows you build unit tests in and it opens the route to con­tin­u­ous inte­gra­tion in the future.

GIT Man­ual

SVN Book

Mer­cu­r­ial Book