Cloudshapes

As mentioned in a previous post about search functionality (http://thecloudshapes.com/post/127340553897/search-functionality) we have been using Foursquare API to search for Venues around the user’s location.

To make this a viable function we can integrate later into our app we have to be able to handle more than one type of search query.

For instance, the user may enter ’Starbucks’ and we could search for all business locations with that name. But they may also enter something more generic which points to the same results. So entering ‘coffee’, along with other results would also show nearby Starbucks locations.

So far to achieve this, we have been using the Foursquare API, Foursquare over time, have curated a very big database of businesses, more concentrated over some types of businesses and in certain geographic locations than others. Other options were Google Places or Facebook APIs, each with its own issues.

Google Places is unfortunately not free, not for deployment at least. Facebook on the other hand requires Facebook login, same as Foursquare. This is not so bad though. Although we have been hesitant in integrating a Foursquare login integration on our app, we were always planning on developing a Facebook login for our app, Facebook being immensely more popular than Foursquare. But there is another option available to us which we haven’t taken a look yet. Our very own Apple Places API available through MapKit. It’s free without limits to API calls unlike Google and Foursquare. However, it is only available for use for iOS. So, we have to find a way to standardize locations in our database when start getting checkins from both iOS and Android devices when we develop for Android.

At the early stage I have run into some bugs trying to integrate it into the project by replacing our search currently done by Foursquare API with MKLocalSearch from MapKit. So I created a separate test project.

I created a single view application with simply a text field and a button. The search functionality is handled by an object from each of the two classes - MKLocalSearch (lets call it MKS) and MKLocalSearchRequest (call it MKSR).

The MKSR object is allocated and instantiated. There are two fields on this object that we have to set. The first is the natural language query, which is the string that user enters (handles all the types of searches that i mentioned earlier). The second is a region which is the region which to look in. The region parameter is optional and entering no region results in a global search.

We create a MKS object and initialize it with the MKSR. These searches are asynchronous, so the method that fires the search requires a completion handler. The completion handler contains a response and an error variable. The response variable contains the results or our search, which in this case we simply NSLog in our completion block. The error contains the error which has occurred (hopefully nil). All this is code is connected to Button, so clicking the button activates the search.

And, it works. I get the following output when I search with ‘Starbucks’

2016-03-03 12:13:19.505 Local Search[8502:146934] <MKMapItem: 0x7f8949d3b9f0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 531-9208";    placemark = "Starbucks, 657 Dupont St, Toronto ON M6G 1Z4, Canada @ <+43.67151050,-79.42129830> +/- 0.00m, region CLCircularRegion (identifier:'<+43.67151050,-79.42129830> radius 49.91', center:<+43.67151050,-79.42129830>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.506 Local Search[8502:146934] <MKMapItem: 0x7f8949c1bfb0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 535-9984";    placemark = "Starbucks, 494 Bloor St W, Toronto ON M5S 1X8, Canada @ <+43.66554130,-79.40990800> +/- 0.00m, region CLCircularRegion (identifier:'<+43.66554130,-79.40990800> radius 49.91', center:<+43.66554130,-79.40990800>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.507 Local Search[8502:146934] <MKMapItem: 0x7f8949e93700> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 653-8181";    placemark = "Starbucks, 687 St Clair Ave W, Toronto ON M6C 1B2, Canada @ <+43.68142060,-79.42581830> +/- 0.00m, region CLCircularRegion (identifier:'<+43.68142060,-79.42581830> radius 49.91', center:<+43.68142060,-79.42581830>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.508 Local Search[8502:146934] <MKMapItem: 0x7f8949ed9160> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 361-9705";    placemark = "Starbucks, 1-123 Front St W, Toronto ON M5J 2M2, Canada @ <+43.64490922,-79.38345507> +/- 0.00m, region CLCircularRegion (identifier:'<+43.64490922,-79.38345507> radius 14150.46', center:<+43.64490922,-79.38345507>, radius:14150.46m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.536 Local Search[8502:146934] <MKMapItem: 0x7f8949edacc0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 926-0166";    placemark = "Starbucks, 1 Bedford Rd, Toronto ON M5R 2B5, Canada @ <+43.66854190,-79.39717410> +/- 0.00m, region CLCircularRegion (identifier:'<+43.66854190,-79.39717410> radius 49.91', center:<+43.66854190,-79.39717410>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.537 Local Search[8502:146934] <MKMapItem: 0x7f8949edcfd0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 341-0101";    placemark = "Starbucks, 205 College St, Toronto ON M5T 1P9, Canada @ <+43.65855350,-79.39552950> +/- 0.00m, region CLCircularRegion (identifier:'<+43.65855350,-79.39552950> radius 49.91', center:<+43.65855350,-79.39552950>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.538 Local Search[8502:146934] <MKMapItem: 0x7f8949edeca0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 977-6454";    placemark = "Starbucks, 407 Yonge St, Toronto ON M5B 1S9, Canada @ <+43.65952840,-79.38207650> +/- 0.00m, region CLCircularRegion (identifier:'<+43.65952840,-79.38207650> radius 49.91', center:<+43.65952840,-79.38207650>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.539 Local Search[8502:146934] <MKMapItem: 0x7f8949ee0590> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 934-0881";    placemark = "Starbucks, 1250 Bay St, Toronto ON M5R 2B1, Canada @ <+43.67073800,-79.39017680> +/- 0.00m, region CLCircularRegion (identifier:'<+43.67073800,-79.39017680> radius 49.91', center:<+43.67073800,-79.39017680>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.540 Local Search[8502:146934] <MKMapItem: 0x7f8949ee2600> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 588-7979";    placemark = "Starbucks, 941 College St, Toronto ON M6H 1A6, Canada @ <+43.65342680,-79.42650130> +/- 0.00m, region CLCircularRegion (identifier:'<+43.65342680,-79.42650130> radius 49.91', center:<+43.65342680,-79.42650130>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; } 2016-03-03 12:13:19.541 Local Search[8502:146934] <MKMapItem: 0x7f8949ee49b0> {    isCurrentLocation = 0;    name = Starbucks;    phoneNumber = "\U200e+1 (416) 483-6850";    placemark = "Starbucks, 43 Eglinton Ave E, Toronto ON M4P 1A1, Canada @ <+43.70672730,-79.39715580> +/- 0.00m, region CLCircularRegion (identifier:'<+43.70672730,-79.39715580> radius 49.91', center:<+43.70672730,-79.39715580>, radius:49.91m)";    timeZone = "America/Toronto (EST) offset -18000";    url = "http://www.starbucks.ca"; }

Now I have to integrate it into the Cloudshapes project and see what I am messing up. I am likely to post the link to the Git Repo of the Local Search project I created in the future.

Now our little project is just about big enough where it would start to hurt us if we lost our work. Until now we have been committing our work to our local repository as we make incremental changes to our project.

GitHub is a fine service that allows you to push your project on the cloud. Pushing code off to GitHub from Xcode happens to be very simple. You simply provide the public address of your online repository on GibHub for you new remote on Xcode.

Project -> Source Control -> Cloudshapes — <Some Branch name>  -> Configure Cloudshapes ..

Remotes Tab -> + <New Remote>

And voila … after a few every commits we may choose to push the repository off to GitHub. We may even decide to do it every commit.

Our app will generally support two types of search. Users can search for either other users or venues. Right now we have a barebones implementation of venue search. A user search will search cloudshapes user database and find matches. Whereas a venue search shows you matching venues by looking up the foursquare database.

So far, we have added a search bar on top of our ‘Around Me’ tab. We may have referred to this as the ‘Skyboard’ before. We shall use those two terms interchangeably. Final decisions about the search bar or the types of search we shall provide in our app is still up in the air. So we haven’t decided on things such as whether the search bar is global (appears in all tabs), whether we provide more search functionality other than just people and venue search, and so on.

We are using a Objective C Library to interact with the Foursquare API. This saves us a lot of time. Without all the bells and whistles all  it does is take parameters in methods and make HTTP Requests to Foursquare and parses the JSON Response into an object that we can use in our app. Behind the scenes it’s much like the requests we make to our server.

Now that we have all that out of the way, off to the good part, which is the actual location search that we perform. We need two new view controllers to this - a UISearchController, and a UITableView.

UISearchController - This is the search controller that orchestrates the search. It keeps a reference to the search bar that this search controller is serving. It manages things like the presentation of the dimming view during search (optional), or results table-view under the search bar, and some other things.

SearchResultsTableViewController - This is the view-controller that manages the table-view that is displaying showing search results. At the very basic, it’s just a table-view controller  with the UISearchResultsUpdating protocol (we actually use the UISearchBarDelegate protocol instead). This is the heart of what drives the actual search.

So, where does it all come together?

In viewDidLoad of our Skyboard View Controller

self.searchResultsTableView = [[CSSearchResultsTableViewController alloc] init];[self.searchResultsTableView.tableView registerClass:UITableViewCellStyleDefault forCellReuseIdentifier:@"search cell"];self.searchController = [[UISearchController alloc] initWithSearchResultsController:self.searchResultsTableView];self.searchController.dimsBackgroundDuringPresentation = YES;self.searchController.searchBar.delegate = self.searchResultsTableView;[self.view addSubview:self.searchController.searchBar];self.definesPresentationContext = YES;[self.searchController.searchBar sizeToFit]

This code creates both the UISearchController, and the search results controller (as the search controller’s results controller).  

One thing is left a subtlety, (perhaps because of the way we have presented it) is the following :

Showing the user's location on a map on the iPhone is fundamentally TWO PROCESSES, not one. The first - Getting the users location - information about where the real users is located on the real world we all live in. The second - Displaying the users location - that pin(avatar) that represents the user, in the map on the phone(virtual world) that represents the real world we all live in.

So we use two frameworks from the SDK, CoreLocation and MapKit.

We set two properties on our View Controller -  a CLLocationManager, and an IBOutlet to a MKMapView.  We also set our view controller to be the delegate of both the MKMapView and the CLLocationManager making sure that we have added the protocols in our header file. Having done this, we can respond to events whenever we get location updates. As always, please read the documentation for more information about more delegate methods.

In our viewDidLoad we start updating location on our location manager. Next on our MKMapView, we set showsUserLocation. We also set other properties on the view controller, however they are not so interesting and we shall skip on the details. So every time the location updates, showsUserLocation changes the pin to the appropriate place on the map.

We do other things manually, like panning and zooming the map to the location of the user. This done using the map view delegate methods. mapView: DidUpdateUserLocation: is whether we put our zooming and panning code.

One of the main features of Cloudshapes is that it is location aware. Posts made on Cloudshapes are reverse chronological, filtered by location.

To achieve this, each post must also encapsulate information about the location of the user where he/she posted the content on Cloudshapes.

So far, we haven’t talked much about the overall structure of our app. Readers following so far perhaps don’t even know what we trying to build over here. This has been done on purpose. This blog is to log our progress as we develop the app. The actual idea will be apparent once we "launch".

But, I thought I would add this so that the reader gets a glimpse into our perspective.  This is so that as we go along, the reader has a better understanding of the reasons for the choices that we make during the development process and how those affect the finished product.

We are currently calling Cloudshapes, “The Local Social App”. The goal is to connect users who are located in the vicinity of each other.

Most apps that require a user to register and be logged in when using the app implements login persistence. Login persistence enables the user to not have to enter their login credentials every time they use the app. A user simply registers and logs in the first time they use the app. On the subsequent launches, the app remembers which user was using the device and automatically logs the user in.

So far, we haven’t talked about how save any information on the device itself. Any information in our app comes straight from our server or is entered by the users themselves.

iOS provides us with a class called NSUserDefaults. This is a singleton class. A singleton class is able to instantiate only a single object. Detailed information about Singleton classes or NSUserDefaults is beyond the scope of this post.

We use NSUserDefaults and save some basic information about our user, for instance we can choose to save the user’s id, a URL string for their profile picture etc. At the moment it is too soon, to list all the information we shall use NSUserDefaults to persist. We just simply use the objectForKey: method to save the above mentioned information in the NSUserDefaults object the same way we would be storing it in a NSDictionary. After that synchronize in order to save this information in permanent store.

In our above example, the next time the app launches, we may choose to use the user id to identify the user, thus skipping the login process to bring the main content of our app faster.

Posts made by users appear in a TableView. A TableView arranges data in cells. Cells extend the full width of the screen are placed one after the other vertically. The user scrolls with a drag gesture to reveal more content in the cells above or below the current cell (usually cells) that is (are) being displayed currently on screen. In short, each Cloudshapes post is represented as cells in a Table View.

Among other data, a post consists of text that is of variable length. Depending on this length is the number of lines that the text spans. This number of lines is mainly what requires us to implement dynamic height.

In layman terms - More text = More lines = Taller UITableViewCell.

UITableViewControllers in iOS have two interesting delegate methods. tableView:cellForRowAtIndexPath:   - lets call it cellFRAIP for short tableView:heightForRowAtIndexPath: - similarly we will call it heightFRAIP

For our purposes we can think of an Index path as just a numbering (index) of cells. So the first post that is displayed to the user is contained in a cell with indexPath 1, and so on.

By default in iOS all cells span the width of the screen. But the height of the cells may vary. To achieve this heightFRAIP is called first. This method returns a height value of type CGFloat. Once we have that we basically have the the dimensions of our UITableViewCell sub-class. Next cellFRAIP is called, this is where we create all the objects that go inside the cell.

Sounds, very straight forward right? WRONG !!!

It would have worked fine if my Fairy God Mother somehow told me how tall each cell was going to be. Since, she’s busy and we don’t have any data stored about the individual height, how do we go about this?

I don’t know whether there is a better way of doing this, but one way I discovered people were achieving this is by creating a Prototype Cell. We are not talking about a Storyboard Prototype Cell. It is just a property of our UITableViewCell sub-class which we declare in our custom UITableViewController sub-class. So now, when we call heightFRAIP we use this prototype cell, layout some of the things in it and record the vertical heights of these things laid out. Adding up all the heights gives us the height of the cell which we pass back.

cellFRAIP then uses this height, creates a cell, and returns that cell so that it can be drawn on screen.

I expected this one to be trivial and follow mostly like the last one. But like with all others, it was no so.

Before I get into, lets lay out a basic example of where we might use this in our app. The answer is pretty much anyplace where you would want user generated media within the app. So anything that is user generated non-text data. We go with the most basic example of a photo upload. One place where users might want to upload a photo is in their User Profile Page. 

From the iOS side of things, most of what is mentioned can be done by calling simple methods on objects that encapsulate the information we are trying to send. However, sending file data through HTTP Requests has this very weird format. The mechanism looks almost more low level than what I am usually used to. 

We obtain a JPEG representation of our image and encode it in an instance of NSData. Then, like before we create a HTTP POST Request and set its fields like Content-Type, Content-Length, etc. The Request calls a script and provides the image data to the script to upload to the file system.

We encode the image data (NSData) into the body of the HTTP request. Also you have to encode into the body, information that what this data means - in this case it's an image - and also information about where to store it. 

The way to do this is that each section of information in the body is preceded by a tag defining what the content actually is. So, one section might be the declaration that the data being sent is an image, while another is the image data itself. In case of multiple images being uploaded there are multiple sections each containing the data of a single image. Sections are divided by a boundary string that you have to define. The boundary string is simply a random string that can never appear in your data.  This is what I meant when I said low level. It is used as a marker to divide the "multipart" data that you are trying to send.

At first I had thought of simply thought of going with a regular web host. Probably like GoDaddy or something and just get web space. Then upload the MySQL database on it and then just use php scripts from the app to make queries on it. 

However, then I remembered a friend mention Amazon Web Services (AWS). At first it seemed all arcane and there was a lot of manual reading to get everything to actually work out. But I think that it is going to pay off in the end. Once you get the idea of how Amazon provides these virtual servers the set up is not that bad at all.

So why use AWS? Here’s the short version, since these are all virtual servers, meaning this is just a logically isolated partition of a much larger mainframe. The advantage is that we can keep our app database and our app server separate and scale each one independently on the fly. So back in the days of Facebook when they had to buy entire new servers whenever they were reaching their cap, we just don’t worry about stuff like that. Plus there is a lot of built in that takes care of a lot of utility and security features that does not have to be programmed again. I haven’t had the chance to look at it all, but I urge the reader to have a look at the AWS page.

So, what do we have so far? 

Well, we created an Amazon EC2 instance, which essentially our web server. This is the server that every user connects to through the app. After that we set up an Amazon RDS. This is our database that holds all the information provided by users and generated by the app. 

To test it out we worked on our ‘Register New User’ part of the app. When a new user enters all his account information to register, the app connects to the EC2 instance and runs the appropriate php script. The information is provided to the script, via a POST request. The php script connects to the RDS and enters the information in the appropriate table. It took me a while to get this all set up, since I am doing this for the first time. Also, I wanted to do it right, (or atleast relatively proper) so I didn't want to do something like use GET requests. Google if you care but don't know.

So the question is Swift or Objective-C?

Apple just announced the release for its new programming language for the iOS, namely Swift. So what about Objective-C? Developers are still free to use Objective-C to develop, but now they also have the option of Swift.

At first look, Swift is much cleaner, shorter and simpler than Objective C. Looks a lot like java, with more extensive dot notation. Since we haven't begun writing code yet, this would be a good time make this decision about what language our app will be written in.

Swift is brand new and it is unlikely that there is much help out there regarding Swift, but Apple has an uncanny adoption rate when it comes to anything. Objective C has been around for a while, so it's an advantage for Objective C that way. Then there is that question of porting. One of the reasons we decided to develop on iOS first, eventhough iOS is more $$ is this ability to port easier to Android than the other way around. Where does Swift come in into the equation.

I just read some of the documentation for Swift, and the good news is that it does not have to be one or the other. This thing that Apple calls mix and match. Since Swift is ultimately built on Objective C code, one is able to use both languages in the same project. Thats cool.

As mentioned before, we have already decided to develop our initial version on the iOS platform. Below, we briefly describe the tools that we will be using for this purpose.

Xcode and Objective C for bulding the actual app - This one we are not really given a choice on.

MySQL as the Database Management System - Pretty obvious choice, open source, widely used easily available.

PHP for creating the web service - We use php to connect the database to the actual app. PHP with its built in functions is ideal with MySQL.

That was a very basic outline. It is likely that we will use further tools such as the Google Maps API to work with location services, Foursquare API for connect street addresses and GPS locations to businesses, and  so on. Further updates will be posted regaring developments about these.