My 2016 Challenge : The Foundation

Technically I started work on my 2016 challenge late 2015. The goal remains to have something tangible done as the year progresses. This brings me to foundation of all I intend to build: The Architecture.

As a Software Engineer, I deal with Architecture decisions daily. Making best guesses on future design and ruminating on past bad decisions. In the Agile landscape I have come to terms with that fact that Architecture is really where you land and the initial key decisions are around mitigating risks. How much time one puts in upfront architecture decision depends on what you are building: A shed or a skyscraper. In my case I choose to land somewhere in between.

I typically advocate for a factor of 3 to account for the smallest unit of complexity. In this first round I was focused more on simplicity which meant a single node and single broker where possible.

My current tech-stack includes:

  • MQTT
  • Kafka
  • ELK Stack
  • Cassandra
  • 1 Linux box
  • Programming language choice –  Python
  • Sensor Peripherals (Efergy Electricity Monitor and R820 Tuner)

 

Screen Shot 2016-02-29 at 5.13.56 PM.png

Here is my view from Kibana

Screen Shot 2016-02-29 at 10.06.11 PM.png

 

 

Basics of iOS Networking – Swift Style

Networking in the mobile context largely entails communicating with external entities over the internet. Like most modern web or mobile platforms today iOS supports HTTP.

These network requests are referred to as ‘Tasks’ in the iOS world and there are three basic network tasks you can perform using the NSURLSession API

Data Tasks – These are network tasks where you exchange simple data which typically get stored in memory as a NSData object during server interactivity

Download Tasks – These tasks involve retrieving the contents of a url as a temporary file from a server (supports running as a background activity)

Upload Tasks – These tasks handle similar messages as the download tasks just in the opposite direction by uploading files to a server (also supports running as a background activity)

This API is asynchronous and provides what some might liken to callbacks in Javascript. The example below is a data task (indicated by ‘dataTaskWithRequest’)

Screen Shot 2016-02-11 at 5.26.25 PM.png

‘in’ signifies the beginning of the completion handler block. This call can’t actually be kicked off without calling resume method on the task

data refers to the actual data you expect back and looks like byte stream data when you get the service response. This needs to be deserialized which you can do like below

Screen Shot 2016-02-11 at 5.21.43 PM.png

response gives you details about your response such as status code and such

error gives you detail if there is an error. If there is none you can expect it to be nil. data is nil if an error is returned

This is not the all in all you need to know on iOS networking but at the very least it should give you a thousand foot view of what you need to know make very common network calls in iOS using Swift.

One last point to note. By default iOS limits regular HTTP calls favoring HTTPS calls out of box. So you need to account for extra steps to support network calls to urls that are prefixed with basic HTTP.

 

Delegates in Swift

Delegates in Swift are pretty cool. They work sorta like how inheritance works except that the actions a delegate can carry out are scoped rather than a default inheritance of all attributes or capabilities of the delegator.

One analogy is the President having a delegate to the UN. The delegate can carry out a set of actions on behalf of the President, but can’t really do everything the President can. A delegate is not an instance of what it represents.

The official Apple docs describes Delegation as “a design pattern that enables a class or structure to hand off (or delegate) some of its responsibilities to an instance of another type.”  One such a example is AVAudioRecorder , where a class that uses its instance to record audio can’t tell when it is done recording unless it’s a delegate.

AVAudioRecorder  uses a protocol to define what a delegate can know and do. As the source code shows below

public protocol AVAudioRecorderDelegate : NSObjectProtocol {

    optional public func audioRecorderDidFinishRecording(recorder: AVAudioRecorder, successfully flag: Bool)

    optional public func audioRecorderEncodeErrorDidOccur(recorder: AVAudioRecorder, error: NSError?) … 

}

By simply specifying my controllerView as a delegate I can now tell when recording is done

class RecordSoundsViewController: UIViewController, AVAudioRecorderDelegate {

    var audioRecorder:AVAudioRecorder! ….

    try! audioRecorder = AVAudioRecorder(URL: filePath!, settings: [:])

    audioRecorder.delegate = self

    func audioRecorderDidFinishRecording(recorder: AVAudioRecorder, successfully flag: Bool) {

        <#code#>

    }

}

Now your instance of one class type can carry out activities and responsibilities of another class. You go Delegate!

see more:

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html

How to Alter the Speed of an Audio File in Swift

Assuming you figured how to play an audio file in Swift, now you want to play with the speed of the audio. The rate property of the AVAudioPlayer object is what you need to change up the speed. The catch is that you need to set the enableRate property to true before you can actually do this.

Screen Shot 2016-02-02 at 5.25.11 PM.png

In this example I create a helper function to set things up. audioPlayer is my instance of AVAudioPlayerI set currentTime in my use case to start the audio from the beginning. It is also a good practice to stop the audio before playing.

Screen Shot 2016-02-02 at 5.18.17 PM.png

Then I call that function in my actions

Screen Shot 2016-02-02 at 5.18.29 PM.png

That’s it mainly.

A month with Swift and iOS Development

I never would have imagined I would touch iOS development. I have been an avid Android user since the birth of the Samsung Galaxy series. Actually, I was led down that path mainly because my experimental jailbroken 3gs iPhone was buggy. I had the last of it when the glass shattered on a vent and had trouble replacing the glass myself. I never thought I would be back to an iPhone. Besides, Android devices are just more open and allow for easier experimentation.

Enter 2015 when I thought I would give the iPhone another try after 5 years of hating. The iPhone 6 is a nice design. I was intrigued about the experience of a seamless experience across multiple form factors and I have somewhat liked what I have been my Mac, iPad and iPhone. I still think the notes app sucks (so glad google keep is now on iOS).

Having done quite a bit of Android dev and mobile dev using PhoneGap in its early days, the thought of using Objective-C was scary enough for me to never consider iOS development. That all changed with Swift. I have grown to love the expressiveness of languages like Ruby and Python. Any language that follows a similar form is sure to catch my attention. Swift has done just that.

It is not quite as flexible as Python, my go to prototype/hack language, but for a mobile development and on iOS Swift feels like a home run. I actually enjoy doing this now and finally gave the development tools that Apple provides a chance. I am one happy customer. The idea of writing this post really came from a Udacity course I’m currently going through titled Intro to iOS Development with Swift. I would highly recommend it for anyone looking to get their feet wet.

All in all, I like Swift and development for my iOS devices is now an exciting endeavor I never thought I would embark on.

Blog at WordPress.com.

Up ↑