17
Feb 15

Magic Tricks in iOS Development

Yes, magic :-),

I started working in a firm that develops solutions for events like congress etc. As you know, in professional life, you need to deliver your products on the time. If you are doing repetitive tasks for the products, you definitely need to do some magic tricks.

r2-d2_fixing_royal_starship

My first recommendation before telling you my magic tricks, for the iOS developers(this is true for other developers as well) is to understand requirements, priorities very well. What is the most important thing to do first? A feature or half-finished mobile app that is delivered on time.

Secondly write clean code, you know very well why. Ask Uncle Bob.

And now magic trick number one: Most of time I got frustrated by lack of automation for taking screenshots of your application inside Xcode. Well I found a workaround, which is above my expectations.

It’s called Snapshot.(I highly recommended it. Kudos to its author.) It generates the screenshots of your app by executing a UI interaction script. Author of Snapshot, Felix Krause, also has small tiny components that can be combined with fastlane to automate the whole deployment process.

I am using Swift for a while and I want to recommend you the third party libraries that I use, and all of them are magical.

  • JSON.swift, very simplistic NSJSONSerialization wrapper by Dan Kogai
  • Async.legacy, Syntactic sugar in Swift for asynchronous dispatches
  • SQLite.swift, by Stephen Celis, saves you tons of headaches if you are using SQLite in your project. Plus has a very well-written documentation.

My final advice is, even though the 3rd party libraries are tempting at first, later you can get headaches too. Please be careful while choosing a 3rd party library. It may be buggy, make sure that you really need it.

The libraries that I shared with you above, are the ones that I really like. If you find a bug in any library that you use, please don’t forget to report it or fix it and send your patch to the author.  It will be very useful for other suffering developers.

And may the force be with you!


19
Dec 14

Protocols to Closures in Swift

After releasing Socivy in a very short time, it required some refactoring in the API level. Since MVC pattern is in the foundation of the iOS development, without touching UI components, I can directly refactor only API part of the project.

Well, I highly used protocols in my implementation. For instance, if user makes a request to get available routes in the system, it uses already constructed SocivyAvailableRouteAPI to make fetch routes from the API. It handles the requests asynchronously and returns the response by calling delegate function like routeRequestDidFinish(), this is enormously helpful for me to separate controllers and models however, after increases in our API methods, unfortunately it increased protocols and unnecessary repetitions.

Not only this, increased a spaghetti code, it also affected the compile time. A big advantage was that everything was explicit, and implementation was pretty fast, it helped  our tight development schedule.

I will be adding a chatting feature for Socivy for the end of the semester for CS392 course. Before starting the feature, I thought it would be better to refactor the code and use closures and Factory and a kind of Facade pattern to reduce redundancy and decrease number of classes.

Because of the architecture of SocivyAPI security, it requires re-logins sometimes. Whenever an API request fails due to expired session, it should automatically restore and continue the calling the action and trigger the callback to update the user interface. I subclassed NSURLConnection, added completionHandler and errorHandler:

  • completionHandler: (response:NSMutableData->())?
  • errorHandler: (error:NSError->())?

Basically if request returns successfully or with an error, it will be handled by these handlers. Another problem was the data validation, NSMutableData must be a convertible to a valid JSON object. For that, I implemented a Model layer that gets exactly same handlers but this time completionHandler gets JSON as parameter. In that layer, I also handled session expires, it automatically re-logins after the validation, so no need for extra care for all methods that require authentication.

However, delegates must be removed after these, since the protocols are removed. For instance:

It is currently on ViewController side:

With closures, I think it is much cleaner than delegates, you can handle different cases, much better than delegates. On the other hand, you should never do this:

This is not very expressive, and would eventually lead to a callback hell.


24
Oct 14

On Security, Socivy

A big coincidence that last year, I wrote a post about securing a RESTful API, well this year, I experienced the same challenge, but this time in Socivy, we implemented the actual things that I mentioned in that post.

Screen Shot 2014-10-24 at 01.30.18

This semester, because of the price increases in our shuttle service, old OzU-EMS, as Socivy team, we decided to do something about it. I attended to the Student Union’s meetings, which they came up with a solution. It was making a call centre that find drivers and passengers, and match them.

We thought that it’s a very inefficient and frustrating work. On that time, it was necessary to this manually, because there were not any available solutions. At 00:30 AM, we decided why not, let’s write something. A simple car-sharing app that has the popular stops in it and can send notifications to the passenger and driver. I started the initial designs of the iOS app for it. Well, the whole development process is a long story, which we did everything that can be possibly wrong and learn it by doing. I am planning to write it whole development process in detail some time.

After finishing our web site, and hitting almost 6.000 page views, it was time to write an API for our system. Since privacy related data(phone numbers, passwords, plate number etc.) transferred throughout our system, we thought it’s necessary to take some actions for it. We put a SSL layer, both to our web page and API. However we were uncertain about deciding:

  • Saving email and password in the app or not.
  • Sending the data over HTTP parameters or in headers
  • Obfuscate or not (we are scared about decompilation of APK packages of Android)
  • Storing our API keys inside the code or in a file or in an encrypted file
  • Should we care about replay attacks which can exploit our API

Well, first thing about security, your protocols should be hidden. It’s very obvious to see that nobody knows how to do it best. By saying best, I know that it’s impossible, but we don’t want to left our front door open to bad people. For this reason, sorry I wish I could tell you all the technical details. 🙂

Even though, it is not a commercial application, but we wanted to make it in level that it can compete with them in terms of security.

  • SSL is necessary, for lot’s of reasons.
  • You should send your parameters in POST data or HTTP headers, not in parameters.
  • Obfuscate it, if you can. if you don’t want your precious algorithm to be stolen, store it to your remote server.
  • Well, it depends. You should be aware of that if someone installs your app and jailbreaks his/her iPhone. They can get access to the file that you provide. It’s better to an encrypted file, instead of putting inside the code.
  • Even if you have SSL, you can get frustrated about replay attacks. You need to find a way to eliminate that. You can put the timestamp while using the API, but it can be trivially changed by hand. I recommend you to find a way to make requests expire, you may use tokens.

Bonus: What is Socivy? How to pronounce it? (it is not sokivay, soçayvi, sochaywi)

Until next time!

 


03
Jun 14

New Lang from Apple, Swift – Making a HTTP Request

Bye bye Objective-C, welcome Swift!

Today, Apple released its new language which claims to lose C from ‘Objective-C’ and much more. I downloaded Xcode 6 Beta and tried to implement a simple HTTP Request, after reading some of their very good-written documentation about Swift. For brief features here, for iBook version here.

My first impression is, it seems like a good language, however popularity of this language will be increase not only by that, but also the great market. The reason why Objective-C is on Top 3 in TIOBE Index, my personal opinion is because of that.

Update: Well, After implementing Socivy and migrating Dilixiri to Swift, “good” seems to be not enough, for a very young language, it’s perfect. (even though, there are some small problems with UISearchBar with Scope Bar, that’s ok 🙂 )

(Apple may be inspired by Go-Lang for the type annotations.)
(Check Swift REPL mode, you will like Playground feature.)

Swift syntax seems much clear while comparing with the Objective-C version of the code above, despite its cleanness, I believe some of the core Objective-C libraries must be rewritten.

As you can see above, for making an HTTP request I have used old NSURLConnection class, and called a very sendAsynchronousRequest method. For making libraries both accessible from Objective-C and Swift, seems like Apple intention currently, so I am not expecting a huge API changes on core libraries such as UIKit etc. Apart from that, there will be dozens of new third-party libraries which will be more swiftic(like pythonic) than Objective-C ones. (For instance, HTTP library for python, requests is more pythonic than standard python library for making http requests)

For projects that are awaiting me on iOS platform this summer, it is exciting yet, a bit sad to put Objective-C behind. And yes, I think I am going to go with Swift for these projects. 🙂

Small note: My async handler unables to access to the UI, for some reason I don’t know(weirdly sometimes does). I tried to implement it by looking some of my old Objective-C implementations. Since there is nothing on the web about Swift now. (It is released just today, come on!) If you know why, it would be great if you write a comment.

Update: This is because of GCD. Please check this detailed explanation.