WWDC 2007 2008 2009 2010 2011 2012 2013 2014 2015
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
MKMapRect zoomRect = MKMapRectNull; | |
for (id <MKAnnotation> annotation in mapView.annotations) { | |
MKMapPoint annotationPoint = MKMapPointForCoordinate(annotation.coordinate); | |
MKMapRect pointRect = MKMapRectMake(annotationPoint.x, annotationPoint.y, 0, 0); | |
if (MKMapRectIsNull(zoomRect)) { | |
zoomRect = pointRect; | |
} else { | |
zoomRect = MKMapRectUnion(zoomRect, pointRect); | |
} | |
} |
import Foundation | |
extension Data { | |
var prettyPrintedJSONString: NSString? { /// NSString gives us a nice sanitized debugDescription | |
guard let object = try? JSONSerialization.jsonObject(with: self, options: []), | |
let data = try? JSONSerialization.data(withJSONObject: object, options: [.prettyPrinted]), | |
let prettyPrintedString = NSString(data: data, encoding: String.Encoding.utf8.rawValue) else { return nil } | |
return prettyPrintedString | |
} |
Widget tests should cover the main use cases in your app. They test the UI and logic, but don't need to be granular unit tests. The important things are
- You have good code coverage. 90% + is usually a good indicator the main use cases are covered
- The tests cover the full app - not isolated components
- Tests run as integration tests on the target platforms
Most state management approaches are fine. The important thing are:
- The codebase chooses one and uses it consistently
- There is a separation of concerns (presentation, business, and infrastructure).
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/
is intended for code that can run as-issrc/
is intended for code that needs to be manipulated before it can be used
I recently stumbled upon an application developed with Flutter, and since it was my first time seeing it, I surprisingly couldn't intercept its requests. After some digging on google, I created this tutorial with the steps that personally worked for me and I wanted to share them in hope to help someone else.
Note that the applications that I tested didn't have certificate pinning implemented. I'll update this file once I get to test an application that has it (if I'll be able to bypass it 😃 ).
To simplify the explanation I refer to the machine that hosts Burp as Kali, but you can use whatever linux machine you want.
There are 2 ways to intercept HTTP connections from a Flutter application installed on an Android device (I'm sure there are more but these are the ones I know). Intercepting requests by changing the proxy settings of the device, through the classic settings of Android, doesn't work in this case, since Flutter applic
- Introduction to Functional Programming Johannes Weiß - https://vimeo.com/100786088
- ReactiveCocoa at MobiDevDay Andrew Sardone - https://vimeo.com/65637501
- The Future Of ReactiveCocoa Justin Spahr-Summers - https://www.youtube.com/watch?v=ICNjRS2X8WM
- Enemy of the State Justin Spahr-Summers - https://www.youtube.com/watch?v=7AqXBuJOJkY
- WWDC 2014 Session 229 - Advanced iOS Application Architecture and Patterns Andy Matuschak - https://developer.apple.com/videos/play/wwdc2014/229/
- Functioning as a Functionalist Andy Matuschak - https://www.youtube.com/watch?v=rJosPrqBqrA
- Controlling Complexity in Swift Andy Matuschak - https://realm.io/news/andy-matuschak-controlling-complexity/