#reactivecocoa

今天的東西要分兩篇寫

之前下載圖的地方: 

https://github.com/julianshen/RAC-GitHubUserSearch/blob/9183f978ee782fbf8e118c79a9557f294e8aa87b/GithubUserSearch/ViewController.swift#L65-L84 

有個缺點, 就是當UITableView已經被更新或是滑到下一個頁面時, 圖片下載並沒有被中斷, 但cell又是被回收使用的, 導致前一張下載完後還是會先顯示到UIImageView上去, 這樣會造成圖片跳來跳去的

最直覺的想法是當圖還沒下載完之前這個cell已經要被重複利用到別地方前就終止下載, 但在RAC裡面, Signal是沒辦法被中途停止的, 但可以被unsubcribe, 因此改寫成:

https://github.com/julianshen/RAC-GitHubUserSearch/blob/aa3754787f2eec9e779493dffc65a65aa918c50a/GithubUserSearch/ViewController.swift#L81-L96

Since RACChannelTo is not available under Swift (with Reactive Cocoa v2.x), you have to do the following to setup a two-way binding between e.g. a UISwitch and a model property:

I've been doing Objective-C for almost 5 years (woo!), so at this point I think I have a better understanding than most of Apple's motivations and intentions, with relation to building the language.

That said, recently I've been loving working with Go, and there's a few reasons for that.

Not traditionally object-oriented

With the rise of ReactiveCocoa, I've been thinking about what programming principles might work for UI-driven frameworks. Go is not traditionally Object-Oriented. You cannot inherit your Cat class from Animal, but you can anonymously embed an Animal into your Cat, so it gets all the traits of Animal. That's because you don't have objects, you have structs and interfaces. Interfaces are functions that act on structs. This doesn't sound quite that different than OO methodologies, but it's a big distinction when thinking about how to construct your software.

Gothic (go-like) programming seems like it would be a great style for people looking to explore signal-driven frameworks, which Go is great for.

Type inference

UIView *view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 320, 480))]

I write that dozens of times per day when doing iOS development. In Go, it would look like this:

view := UIView{CGRect{0, 0, 320, 480}}

Considering how often I write that, I would love type inference to clean up my code. Type inference is the biggest reason writing in Go feels like working with a scripting language.

Garbage collection

Let me start off by saying, ARC is amazing. I think what Apple's done with LLVM, and what it's enabled is one of the best things I've seen in my short career. That said, not having to worry about ARC not cleaning up properly, or where to use a strong vs. weak reference does get tenuous. If software development is about reducing mental strain on a programmer, then garbage collection is something that goes a long way to that.

Native concurrency

Go handles concurrency in a few ways. The simplest is to just stick the go keyword in front of your method, and it will run it asynchronously.

doSomethingAwesome //Synchronous go doSomethingAwesome //Asynchronous

The second is channels. As an Objective-C developer you can think of channels similarly to NSNotifications. You pass values to a certain channel, and it responds accordingly, as you've set it up to respond. One nice thing is that unlike NSNotification it's statically typed, because this mechanism is built into the Go language. Channels also can talk in both directions, so you can pass messages back and forth along a channel. package main

import ( "fmt" "time" ) func main() { ok := make(chan bool, 1) go doSomething(ok) fmt.Println("Waiting") <-ok fmt.Println("Did something") } func doSomething(ok chan bool) { time.Sleep(time.Second) ok <- true }

I don't know about you, but I'd much rather be doing concurrency this way rather than thinking about what thread to run a function on.

Packages

One thing that Objective-C has struggled with for 30 years is namespaces. JFMyClass, AFNYourClass, THOSomeOtherClass! All this prefixing is done to avoid collisions. The accepted practice is to now prefix your classes with 3 letters, because that will solve everything obviously. If your implementation of a class has a method doSomething, and yours does as well, with Objective-C's dynamic runtime there is no way to know when your version will be ran or mine will. Go solves that in the classic way, with packages. Packages can be built into static libraries, which get put into your go directory (where all libraries are stored on your computer).

Go as a tool

Go has built in a built in go tool, which is terrific.

go get

go get fetches remote repositories and installs the packages and dependencies. In fact, you can even import from a url, like import "github.com/go-sql-driver/mysql" and have your MySQL driver ready to go when you compile your application.

go fmt

Isn't it awful when you use BSD style brackets, and your coworker uses Allman, and you want to use K&R? Go only has one style. You run the go fmt tool, and it automagically converts all the brackets, new lines, and everything else to one standard go format. Most IDE's have built in support which runs the go fmt tool when you save the file, so your code always looks right.

go test

Tests are built into the language. Tests live in the same package, so you don't have to worry about exposing any variables just for your test cases' sake.

go be happy!

This one is just my personal advice.

Summary

Go isn't the world's most perfect language, but it's one of the biggest advancements for software development principles in a while. That's why I'm excited about it, and I'd implore you all to try Go!

Start to the new year and i'm far to late to join the reactive cocoa party. But getting started is better then nothing. Just uploading some useful links to anyone trying to get started.

Obviously the first point of call would be to read through the github repo for reactive cocoa. Will give you a overview and some examples on how to use the library. 

https://github.com/ReactiveCocoa/ReactiveCocoa

Read up on the overview and make sure to check out what and what is not deprecated. 

Next up check out  Matt Thompson's blog. 

http://nshipster.com/reactivecocoa/

I pulled the sample ios project aswell however it was pointing to a older deprecated version you might want to make a few adjustments. 

for example 

RACBind has now been replaced with RACChannelTo

So in the example project you will see

[self.view.textField.rac_textSignal subscribe:RACBind(self.text)];

you are going to want to replace it with

[self.view.textField.rac_textSignal subscribe:RACChannelTo(self, self.text)];

The same thing kinda applies to RACAble so you want to replace 

RACObserve

[RACAble(self.text) subscribeNext:^(id x) { NSLog(@"text: %@", x); }];

With

[RACAble(self.text) subscribeNext:^(id x) { NSLog(@"text: %@", x); }];

Do these quick fixes and everything should work. Also dont need to remind you to run through the install steps be it via cocopods or the traditional way. 

I'm finally getting around to typing up my notes from MobiDevDay.

MobiDevDay is a single day, a mobile-focused, polyglot tech conference held in Detroit. This year's event was held May 4th, 2013 at Cobo Hall. This was my first time attending this conference and I went into it not knowing what to expect. I ended up being very impressed by the crowd turnout along with the overall quality of the talks. I'm already planning on attending next year and would recommend it to anyone else that is interested in this type of stuff.

Talks I attended

Keynote: Engineering is Hard by Mike Lee

Mike Lee is a well-known in the Apple developer scene. He's worked with Wil Shipley at Delicious Monster, worked on some of the more popular apps from the early days of the App Store and has worked at Apple. He also founded Appsterdam and is currently working on educational science games with The New Lemurs.

Mike's talk focused on lessons he has learned about software engineering over his years in the field. He laid out some good tidbits from his experience like:

"Being the exception is something you only see in hindsight"

"Solve boring problems, but don't make boring products"

He told people not to bother making games, even though Mike has made games in the past and his current company is focused on educational games.

"Engineering is a gas, it will fill any container you put it in"

During the talk, he mentioned Michael Jurewitz's (@Jury) five part (1 2 3 4 5) series on app store pricing. When he put Juewitz's URL up on a slide, I think every developer stopped listening to make a note of the URL

He mentioned how being good (and knowing it) is one of the biggest barriers to being great

After following Mike for so long on the internet, it was was great to see him in person.

Mobile Accessory Development by Terry May

Terry May showed off a side-project that he has been working on during his 20% lab time that he gets at his employer Detroit Labs. The project involved using an infrared thermometer sensor to create a thermal vision application on an Android tablet. The data from the sensor was overlaid onto the video coming from the tablet's camera so you could see if it is hot or cold. During the demo, Terry held up the tablet and pointed it at a hot beverage. You could then see that the beverage was hot because the tiles on the screen would turn red.

The device Terry created included the IR sensor and an Arduino mircocontroller that processes the data from the sensor. The Arduino is then hooked to the Android tablet via Bluetooth SPP. The whole device was then mounted to the back of the tablet and powered off a secondary battery. During the talk, Terry showed the different revisions he went through and how he did the hardware design for the device. Terry has plans to refine the design to use a Bluetooth 4.0 low-energy device that should be a bit more elegant.

I couldn't find any slides for the talk, but I did find these old slides Terry gave at a previous talk showing an earlier version of this device. Terry does have the Android software up on a Github repo which can give you some idea of how the software side works.

This talk served as another reminder of how things that you might have thought expensive/impossible ten years ago are no longer that way. I wouldn't have imagined a decade ago that I could buy a $70 thermal IR sensor and be able to hook it to my phone to give it thermal vision. It would have seemed too much like a sci-fi/spy type of thing beyond the reach of something I could obtain.

Web to Mobile with PhoneGap by Erik Daniel

At work we've been using HTML5 and JavaScript to build applications with a technology similar to PhoneGap. I figured it would be worth my time to check out Erik's talk to see what else I can learn on this topic. This talk seemed to be very popular since the room was at capacity.

During the talk Erik showed how using PhoneGap helped him to deliver a product for Volkswagen in two weeks by being able to re-use existing HTML assets. He walked through the goals behind PhoneGap and showed the various device functionality you can access via JavaScript APIs. He also talked about how you could leverage existing web developers to work on mobile applications that can run on all the various mobile devices that are available now.

Towards the end of the talk he showed off a few different tools that can help you build HTML applications that are optimized for mobile platforms:

Intel XDK - this is a web-based IDE for developers to make a HTML5 application and package it as PhoneGap apps for all the major platforms.

PhoneGap Build - A "build as service" tool where you upload your HTML, JavaScript and images to their website and all the compilation and packaging happens on their servers. At the end you get to download the compiled applications that are ready to be installed on your device for testing.

Ripple - Ripple is an open source emulator that BlackBerry (my employer's parent company) developed for mobile HTML5 development. It can support testing with various HTML5 frameworks. Erik mentioned that this was one of the best tools for testing and previewing your application on your development workstation.

Erik was a funny presenter and his talk succeeded in providing a good overview of PhoneGap and other related technologies.

HTML5 Mobile app in AngularJS by Jason DeBoever

During this talk Jason walked us through how to build an example application using AngularJS. AngularJS is a client-side MVC framework for making web applications. I had never heard of AngularJS before, but Erik mentioned it during the PhoneGap talk and recommended everyone should check it out. Based on Erik's recommendation, I switched up my plans and decided to attend this talk instead. This was another packed classed with people actually standing through the talk since there weren't enough seats.

During his talk, Jason showed a few slides talking about AngularJS before he dove into working on the sample application. He actually live-coded the sample app which was brave, but it might have been better if he recorded it beforehand as a screencast. Jason put the code for the sample application on Github if you wanted to take a look at what AngularJS looks like. I found that I really liked it compared to other client-side MVCs I've looked at like Sencha. Instead of trying to do everything in JS, AngularJS views looks more like regular HTML and I think that makes it a little easier to understand.

ReactiveCocoa or: How I Learned to Stop Worrying and Learn FRP by Andrew Sardone

In the past I read a few articles on ReactiveCocoa, but I never really got it. After Andrew's talk, I get it. He very cleanly laid out the ideas behind ReactiveCocoa and then went into several examples showing how to code in ReactiveCocoa. He ended it with an example where an existing Cocoa app was modified to make it work with ReactiveCocoa.

Andrew tweeted a link to the video of his talk after the conference. If you are interested in learning more about ReactiveCocoa, I'd recommend checking it out. The slides and code used are also available on Github.

My mind was blown by what I saw. During the talk, I started thinking of ways to re-write existing code to use ReactiveCococa. I've since backed off some of those ideas since I don't think it makes sense to do a full re-write. Instead, I'll probably try to use it for the next Cocoa project I come up with.

Debugging iOS by Dave Koziol

Dave gave a great presentation on debugging techniques for Mac and iOS applications. There was a lot of stuff in this talk that I already knew (don't ship code with warnings, use the static analyzer), but I did pick up a few gems:

In the Xcode debugger, you can drag the green instruction pointer around to skip executing lines of code.

You should test with release builds on actual devices. Since this is the actual binary that will run on the device, you should really be testing it instead of the debug build. I know there are many times where I've just done tests on debug builds and never bothered to re-test the release build. This is something I need to do in the future.

Beware the watchdog. Most developers know that iOS has a watchdog process that will kill processes that take to long to perform certain tasks. Dave pointed out that the watchdog process is not actually running if you are running the application via the debugger. This means that not only should you test the release build of your application, but you should also test it disconnected from Xcode so you can see if the watchdog ends up killing your app for some reason.

He showed the power of some of the different types of breakpoints you can set like the logging breakpoint or a symbolic breakpoint.

You can actually execute methods from the lldb console. This showed me that I really need to get better at using the lldb console and learning about what it can do.

Dave also tweeted the slides out for the talk. He mentioned that he often gives this talk at conferences. I'd recommend seeing it even if you think you know all there is to know about debugging in Xcode. He is an entertaining speaker.

Give your app a backend using Kinvey, Parse, Buddy by Juan-Carlos Mendez

In this talk, Juan-Carlos discussed his experiences using different methods for working with back-end services on mobile devices. He started by talking about his experiences developing Everest, the startup he founded. Everest is a social network application that needed to do some work with a backend. For the first versions of Everest, Juan-Carlos used RESTKit which is a library for abstracting connections to a REST API. He went through several iterations with this and ended up replacing it with his own custom code. This networking part of the code ended up growing and growing until it ended up being about 69% of the codebase.

Following the experience of having to write his own backend servers and his own APIs to connect to them, he wanted to avoid some of this work for future projects. At this point in the talk, Juan-Carlos walks through some of the options that are out there. He touched on the following:

Parse - Parse was recently bought by Facebook. It has several different services that it provides like push notifications and syncing data to the cloud. Juan-Carlos showed off the power of the cloud data and how quickly you could bind the data to a UITableView in an iOS application using the Parse library.

Kinvey - Juan-Carlos showed off how Kinvey makes it easy to hook into other third-party APIs through Kinvey's API. Kinvey looks like it has a lot more features beyond this.

Appery.io - Juan-Carlos didn't dive into Appery.io too far, but he showed how you can build apps using their tools and having them compiled/built in the cloud.

Based on this talk, I've decided to take a look at Parse to replace some server-side code I was thinking of working on for the iPhone app I built. It may be overkill, but Parse looks like a cool enough tool that it would be worthwhile to play around with.

Talks I missed

Since MobiDevDay is a multi-track conference, I had to miss a few talks that sounded interesting but conflicted with other talks I wanted to attend.

Idea to launch - 13 lessons learned from a product manager by Tricia Cervenan - Based on the traffic I saw on twitter while this talk was going on, it sounded like it was a really well done presentation. Tricia latter tweeted the slides from the talk. I took the time to flip through them and it made me sorry for missing out on this talk.

Coding in Community by Angela Harms - While I was in the ReactiveCocoa talk, there were a lot of cool quotes from Angela's talk being shared. I made a note to go back and check twitter later to see if the speaker was going to post slides or anything. Luckily, Angela tweeted the audio recording from the talk. It was pretty awesome that she went out of her way to make a recording and share it with all the people that missed her talk.. A few days ago I lisened to the recording on my ride in to work. It was a very touchy-feely talk, but she said some interesting things about how to relate with people. I only just now relized she tweeted out slides with synced audio. If you are interested in the talk, I'd recomend the video instead of the audio recording. There were parts of the talk where I think it would have been better to see the actual slides she was refrencing.

Wrapping up

Reactive Programming seems to be the in-thing amongst some of the more experienced Cocoa Devs.

This post introduces the Cocoa specific implementation of FRP, with examples.

ReactiveCocoa is an approach to making Objective-C less imperative and more declarative. It abstracts much of the how and focuses on the what.

Прототипное программирование используется в динамических языках. В частности в JavaScript.

Особенность данной модели программирования в отстутсвии классов как модификаторов типа. Тип обьекта задается исключительно его прототипом. В конечном итоге все обьекты системы можно представить в виде дерева обьектов.

В классическом обьектно ориентированном тоже можно, но там узлами будут классы, а тут обьекты.

Так чем же может быть полезен такой подход?

Очевидным мне кажется его применение в иерархии UIView.  Существуюющую систему типов менять нет смысла, достаточно ее дополнить. 

Идей следующая:

Обьекты должны порождаться от прототипов. 

У обьекта есть только 1 прототип. 

По умолчанию все свойства обьекта беруться от прототипа.

Наследник может перекрывать свойства прототипа.

Каждый обьект представляется как суперпозиция прототипа и измененных свойств.

Что дают нам эти свойства? Они позволят проще выводить повторяемые елементы, и проще шаблонизировать вид.

Например, Вы создаете объект UILabel задаете ему цвет, шрифт и выравнивание. Далее порождаете от этого обьекта другой обьект. И новый обьект обладает теми же параметрами что и прототип!

Далее веселее, при изменении прототипа все наследники изменятся автоматически! За это надо отдельно сказать спасибо KVO и ReactiveCocoa.

Если наследник изменит какое то свойство, оно перекроет свойство прототипа, и не изменения прототипа не будут влять.