SAGRU is the official blog of Simple App Group.

Ending Support for iOS 5.0 and Lower

With iOS 6 being released next week we have made the decision to stop supporting any version of iOS lower than 5.1, this will allow us to save time and provide quicker turnaround on client projects. This also means we won’t have to have any hacks in our code to deal with differences between pre-5.1 and newer OS’s. Simple things like tinting Navigation and Toolbars are no longer going to require extra lines of code or even additional category classes.

We’re planning on updating all of our products to support iOS 6 and some of our upcoming products will likely require it because we want to take advantage of some of the new features. Speaking of upcoming products, we should have our next one in the app store in the next few weeks, and you’ll hear more about it soon.

Staging at SAGRU

On a normal day we’re usually working on a web or iOS application, for both we commit them to Git when we’re done with a feature. This has generally been the stopping point for projects, from here they were either just waiting to receive commits or were cloned to the client’s server. This has been exactly what we’ve needed so far, the only problem it presents is that non-developer workers could only review the web work by either looking at it on the client’s server when it’s in a beta state or over a developers shoulder as they work on it.

As of yesterday that’s no longer necessary, as web projects are committed to their repos a combination of post-receive hooks and shell scripts run which automatically clone them into a web directory. Lighttpd starts serving them immediately on our local staging server allowing everyone in the office to view projects as they are being worked on.

Django Registration, Authentication and User’s Names

I’ve been using Django for a while now for it’s built in admin system, it’s ridiculously easy to setup and create a working admin section for clients. If they want to have testimonials for example, I just add a model and a admin entry for it, sync the database and it’s ready for them to enter content. Every time up until this point I’ve used Django just for the admin of projects, the front-end was usually written in PHP or Ruby and just pulled data in.

A couple of days ago I started converting a client project from consisting of a Django Admin, a PHP front-end and a Ruby API into a single project using Django for everything. Once I started doing this I found that setting up the front-end in Django is extremely simple… unless you need to do any sort of user registration. Now since I haven’t used it for anything more than just an admin before, I might be missing a very important yet easy step to get registration working in no time. I tried a lot of searches to find a way to setup user registration, but I couldn’t find anything simple; all I wanted to do was add a user the Auth module’s user table and just have them not have access to the admin. All I could find were sites saying to use the Django-Registration package or seemed to jump past some parts in using the included auth module.

After a full day of trying to figure things out I caved and forced myself to use the registration package,  I had looked into it earlier but the tutorials were all confusing to me. I finally found one that made sense by Michele Pasin, in which setting up the registration package, the views and the SMTP debugging server are discussed. I followed Michele’s post to the letter and got the entire process working and all of the templates styled to match my project. There was only one thing left that I needed to do, collect the user’s first and last name. It’s not exactly helpful when you’re selling tickets to someone and you don’t know who they are.

This is where I ran into a problem, the registration package doesn’t include a way of registering the user’s first and last name; it doesn’t make sense to me as this data is all stored in the default auth module’s user table which has those two fields. After searching for an hour or so and only coming across sites saying to use the Django-Profiles package along with it I decided to roll my own form that handles it. The Django-Profiles package is a really great tool when you want to collect other information from your users, but it doesn’t make sense to use it for first and last name as the auth module already has those defined and why add another table containing information that should already be handled.

It took me about another hour to get this working and I’m going to detail it here for you so hopefully it helps you (more than likely though it’ll just be a reminder to myself of how to do it).

In my project the app where this is going to live is called shop, you can put this in whichever app makes the most sense in your project.

The first thing we need to do is edit our projectsurls.pyfile and add this line directly above the one that includes the Django-Registration urls.

Next we need to setup the form that’s going to be used. Create a file calledforms.pyand then enter the following into it:

Once the form is complete we need to need to update ourviews.pyfile, just make sure the following is in there somewhere, you can edit it to match your coding style but the important part is where we use ourProfileForm.

Since I couldn’t seem to find when django-registration actually uses theactivation_complete.htmlfile that’s where I decided to put our customProfileForm. Just edit the existing one to match your project’s style and add the following to it.

Now here’s the important part, you need to edit yourlogin.htmlfile’s opening form tag to the following:

This makes sure the user is actually directed to our work after logging in. When they login until they supply a first and last name they will be presented with the form, once they fill in the information they will always be redirected to the homepage (unless you change the redirects in theviews.pyfile).