Menu

Category Archives: IOS

Parse.com is a service that wants to provides a backend for your social media apps. It’s my opinion that Parse is the easiest and fastest way for designers to get into creating social media apps and web sites.

How do we do it now?

The standard method to create a social media app or web site is to create a database and access the database using code written in MySQL. You also need code written PHP to facilitate transactions with MySQL and manage content from the database. This is called the backend. All of these processes happen on a remote computer, your web host.

To have something people can look at you use HTML, CSS, and Javascript. This is called the frontend. You use HTML to structure your web pages, CSS to style them, and javascript to add functionality.

Let’s sum that up. To make a web site that has social media features you need (from front to back):

Parse.com provides a service that removes the need for backend programming from the equation. With Parse all of the backend code and processes are handled by the front end. Parse calls itself BaaS, which stands for Backend as a Service. The Parse service provides a ready made and hosted backend that can be used to build just about any type of social media app or web site.

Parse also saves you time by not requiring you to write backend code, creating and configuring databases and tables. Parse also provides ready made systems for managing user accounts and login. Creating a user login with Parse is as simple as creating the login or sign up form in HTML, CSS, and adding a few lines Javascript.

I know this comes across as a sales pitch. For the record, I do not works for Parse and receive nothing from them. As an educator an educator I see Parse as being the easiest way for students to make their social ideas into truly functional apps.

Who would benefit from Parse

Anyone wanting to get started making a social media network would benefit. Parse is well suited to small groups or individuals who want to get started making a social media site. If your skills are more frontend oriented, HTML, CSS, JS, then Parse will save you the trouble of learning PHP, MySQL.

Parse is targeted at startups and small teams looking to create new social media platforms quickly and easily. I see it as a perfect fit for students, as the focus of our students is on front end design and programming. Building an app with Parse moves all of the work of creating a social media app into the front end, and concentrates programming tasks into a smaller set of more familiar tools: HTML, CSS, and JS.

How does Parse work?

In short the Parse service works with Javascript. Essentially you create objects you wish to save in Javascript, and the Parse server takes care of the rest. To display data from the server you request objects from the Parse server through Javascript. Obviously there is a more to it than those two sentences, but not much more.

What kind of things can you make with Parse?

Any social media web site or App. Parse provides libraries code for Xcode, and Android. You can make mobile Application with much less effort, and I’ll say it again, without having to create a backend service, and database. Check out this page of customers using Parse:

Starting with an Empty Application, you have a program that contains a single class: AppDelegate and no storyboard. How do you build an application from this? Ignoring main.m and other esoteric code, your application begins at application:didFinishLaunchingWithOptions. When this method is called, your application has an empty window ready for you to populate with interesting objects.

The delegate design pattern creates a system wherein one object passes work to another object. The first object stores a reference to another object, it’s delegate, and calls methods in the delegate object.

To make this system work there are two problems to solve. First. the main class needs a reference to the delegate object. The second problem is the need for the delegate object to implement the methods the delegator object will invoke. Without this guarantee your program runs the risk of no working or crashing.

The first problem is easily solved by adding a property to the delegator that holds a reference to it’s delegate object.

The second problem is solved by declaring a protocol. A protocol declares methods and properties that an object will invoke in it’s delegate. Any class that will act as a delegate implements the protocol, and the methods the defined in the protocol.

When the compiler sees a class that implements a protocol, it checks that the methods declared in the protocol are defined in that class. If not you get a warning or an error.

Declare a protocol in the header file above of @interface with:

1

2

3

@protocol ProtcolName&lt;Class&gt;

-(void)aMethod;

@end

Declare a delegate property to hold an object that implements the protocol. The delegate property should be weak to avoid dependancies!

Singleton is a design pattern that guarantees that only a single instance of a class exists at any time. Singleton classes are good for Models and Datasources. The singleton is a great partner with a UITableView as the datasource for the tableview.

In the header file declare a class method that will return the shared instance. The shared instance is the single instance of this class that will exist. This method is also responsible for creating the new instance the first time the method is invoked.

1

+(<span class="s1">id</span>)sharedManager;

Define this method in the implementation file.

1

2

3

4

5

6

7

8

+(id)sharedManager{

staticThings *sharedThings=nil;

staticdispatch_once_t onceToken;

dispatch_once(&amp;onceToken,^{

sharedThings=[[selfalloc]init];

});

returnsharedThings;

}

In the sharedManager method declare the variable sharedThings as static. A static variable remembers its value across invocations of a function. That is, the value is set the first time the function is called, and that value is “remembered” the next time the function is called. Normally you would expect that the variable would be forgotten on each subsequent invocation.

The dispatch_once guarantees that the block is contains is only executed once. In the example sharedThings should only be created once, the first time sharedManager is invoked.

These are a few notes on creating the UITableView. Understand at the time of writing this, I’m a total beginner, so take everything here with a grain salt, and an once of skepticism. The purpose of writing this is to settle subject in my own brain.

As part of the MVC pattern UITableView is a View, so a table view knows how to draw itself. A table view typically needs a view Controller to manage it. A table view always needs a data source. The data source supplies, the number of section, rows, and the content for each row. Typically a table view needs a Delegate. The Delegate handles events generated by the table view.

An instance of the UITableViewController class can handle the role of Controller, Data Source, and Delegate. The UITableViewController, as a view controller, manages a view and this view is always a UITableView.

Any class that manages a UITableView must be a UITableViewDelegate. The data source for the UITableView must be a UITableViewDataSource. These are often the same class, I’m guessing they don’t have to be.

UITableViewDataSource

These two methods tell the UITableView how many cells to work with, and give you the opportunity to populate and configure the UITableViewCells.

Giving the table view the number of rows in a section allows it to get data via the index of that row. Without having to contain the actual data. Essentially tableView:numberOfRowsInSection tells the table view how many cells you will need to work with. When comes time to display a cell, the table view calls on tableView:cellForRowAtIndexPath passing the index of the cell, this function returns the cell; and within this function you populate and configure the cell.

The cell For Row method is more complex. Here is where table cells are created, populated, and configured. The table creates cells only as needed. It only creates enough actual cells to fill the screen. As cells scroll up the page they are recycled and repopulated with new data, with the tableview keeping track of which index is currently visible. This process makes the system much more memory efficient, since the computer holds only a limited number of cells in memory. Imagine your iTunes library with 500, or 1000, or more songs. The table view is really only working with enough cells to fill the screen, maybe 10. If the computer to generate 1000 or more table cells, it would slow down, and become unresponsive. Using this system, the table view is recycling a limited number cells like an escalator, changing the content as the cell moves off the top of the view and reappears at the bottom of the view.

Here the dequeueReusableCellWithIdenifier asks for an available cell from the table, which is stored in cell. If cell is nil, no cell was available, so a new cell is generated. In this case the cell is generated using the UITableViewCell alloc. Then initialized with initWithStyle. Here we tell initWithStyle to use one of the default cell styles UITableViewCellStyleDefault.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

This method tells the table view how many sections you will using. Be sure to set this to at least 1. The default implementation of this methods is set 0.

Storyboard and outlets

To connect a tableview created in storyboard to it’s view controller’s outlets, Control drag from the tableView to the view controller and choose dataSource. Repeat the process for delegate. You want the Outlets dataSource and delegate to read ViewController.

I see many apps that look like web sites. These often feel the need to brand themselves with a logo and company name in the title bar. Or they present the company logo in a splash screen.

An app is not a web site. Apps are small focussed pieces of software. They live on a mobile device, and in that environment they act in a more personal and intimate role. The icon alone should brand the app. Making the conscious decision to launch an app you know what you are looking at.

Here’s a quote from the HIG:

Incorporate a brand’s assets in a refined, unobtrusive way. People use your app to get things done or be entertained; they don’t want to feel as if they’re being forced to watch an advertisement. For the best user experience, you want to quietly remind users of the brand identity through your choice of font, color, and imagery.

Apple published a book called the Human Interface Design Guidelines. This covers everything about how to design computer interfaces. I had a print copy some years ago. You can now read it online. It covers everything from color to working with text in different languages.

Apple has also written an IOS version. Here is a great quote from it.

Deference. The user interface helps users understand and interact with the content, but never competes with it.Clarity. Text is legible at every size, icons are precise and lucid, adornments are subtle and appropriate, and a sharpened focus on functionality motivates the design.Depth. Visual layers and realistic motion impart vitality and heighten users’ delight and understanding.

Native or HTML5?

Starting a new project, you’re likely to explore what would be the correct platform as a first step. Javascript has a lot of buzz right now. There seems to be a movement to do everything in the Javascript language. At the moment you can Write your app with JS, script your server with Node.js, query your data base in JS using MongoDB. Wow, sounds like you can do it all in JS! This is neat but, I feel it’s important to not lose sight of the forest through the trees. In any project it’s really about choosing the right tool for the job.

If we’re doing everything in JS does that mean the browser is the new OS? I don’t think so. There’s a bit of the emperors new clothes in this type of thinking. The thing about JS and apps in the browser is they just don’t live up the promise in many cases. Or, maybe I should say that there is to much promise. JS has a lot of hiccups and performance issues. Writing a program across HTML, CSS, and JS has a lack of elegance, and feels crude and verbose at times. Just because you can do something doesn’t mean you should. Again it’s about choosing the right tool. The big draw of JS for everything is that it leverages a common tool set, on a common platform. This can save time and money which is good, but if you are making an inferior product is it worth it?

I don’t want to sound like I have some axe to grind. I’ve had a lot of fun with JS, and if it’s the right tool for the job I’m more than happy to use it. My point is HTML5 has so much hype people are treating it like it can do no wrong, like its the wunderkind that can do anything. I just want to get real here. JS can do anything, and I suppose that’s a really a great thing. But, just like people, JS is good at somethings and not good at other things. I’m a firm believer that anyone can do anything if they put their mind to it, I’m not saying that everyone can break world records.

There’s a lot to like about writing code in one place using a common set of tools and deploying to every platform. But if the app provides weak and compromised user experience do you want to put your name on it? Look at Facebook. They had an HTML5 app, and the user experience and performance was weak. The way I see it, they essentially shoehorned a web site into an “app”. They obviously bought into the promise of HTML5.

“The biggest mistake we’ve made as a company was betting on HTML5 over native”

M Zuckerberg

It’s fun to think you can recreate all of the nifty transitions and animation of a native app with JS in a browser. But, you’re not really doing your job unless you apply a critical eye and are willing to say that something is falling short of expectation. Kudos to Facebook for owning up to a problem that was theirs.

Is the browser the new OS? Computers are getting faster, and JS can do more in the browser than ever before. But I don’t think this makes JS the be all end all. There will always be something you can do native that will be out of reach from the browser. Either for security, performance or other reasons. The world may spend more time in a browser than all other apps combined but, I don’t want to edit images in Safari, and I don’t think this is where the world is going.