Other captions 🚀

Author: chicio

_posts/2018-09-09-ios-notification-content-extensions.md

@@ -16,32 +16,22 @@ authors: [fabrizio_duroni]
 
 ---
 
-During a workshop I recently attended I had the opportunity to explore a new interesting app extension type available in
- the iOS SDK: Notification Content App Extension. This extension has been added by Apple in iOS 10. By using this extension it is possible to customize the UI of your push and local notification. In this way you can show more  engaging notification to your users :grin:.  
+During a workshop I recently attended I had the opportunity to explore a new interesting app extension type available in the iOS SDK: Notification Content App Extension. This extension has been added by Apple in iOS 10. By using this extension it is possible to customize the UI of your push and local notification. In this way you can show more  engaging notification to your users :grin:.  
 Let's see an example where we create a notification with custom UI using this extension type. To do that I will use some assets taken from the [nasa photo journal](https://photojournal.jpl.nasa.gov/ "nasa photo journal"). You can find the complete example [in this github repository](https://github.com/chicio/Notification-Content-Extension-Example "notification content extension example").
-Let's start from the beginning: add a Notification Content Extension to your app. To do that just select the + button
- in the target section that appears after selecting the xcodeproj file.
+Let's start from the beginning: add a Notification Content Extension to your app. To do that just select the + button in the target section that appears after selecting the xcodeproj file.
 
-{% include blog-lazy-image.html description="add target" width="1500" height="885" src="/assets/images/posts/notification-content-extension-add-target.jpg" %}
+{% include blog-lazy-image.html description="Add a new Notification Content Extension target to the app" width="1500" height="885" src="/assets/images/posts/notification-content-extension-add-target.jpg" %}
 
-The extension that is created contains a `NotificationViewController` that adheres to the `UNNotificationContentExtension`. 
-The documentation for this protocol says:
+The extension that is created contains a `NotificationViewController` that adheres to the `UNNotificationContentExtension`. The documentation for this protocol says:
 
-> An object that presents a custom interface for a delivered local or remote notification.
-  The UNNotificationContentExtension protocol provides the entry point for a notification content app extension, 
-  which displays a custom interface for your app’s notifications. You adopt this protocol in the custom 
-  UIViewController subclass that you use to present your interface. You create this type of extension to improve the 
-  way your notifications are presented, possibly by adding custom colors and branding, or by incorporating media and 
-  other dynamic content into your notification interface. 
+> An object that presents a custom interface for a delivered local or remote notification. The UNNotificationContentExtension protocol provides the entry point for a notification content app extension, which displays a custom interface for your app’s notifications. You adopt this protocol in the custom UIViewController subclass that you use to present your interface. You create this type of extension to improve the way your notifications are presented, possibly by adding custom colors and branding, or by incorporating media and other dynamic content into your notification interface.
 
 So if a `UIViewController` inside a Notification Content Extension adhere to the `UNNotificationContentExtension` we are able to access to the notification content and we can customize its UI. In the extension there's also a `MainInterface.storyboard` that contains a single controller associated with the `NotificationViewController` previously mentioned. We can use this storyboard to customize the notification UI using interface builder.
 So let's start by defining the interface in the storyboard. Below in the image there's the final result.
 
-{% include blog-lazy-image.html description="notification storyboard" width="1500" height="885" src="/assets/images/posts/notification-content-extension-storyboard-notification.jpg" %}
+{% include blog-lazy-image.html description="Customize the notification UI with the storyboard contained in the new created extension" width="1500" height="885" src="/assets/images/posts/notification-content-extension-storyboard-notification.jpg" %}
 
-Then we can fill the UI with the notification content we receive in the `func didReceive(_ notification: 
-UNNotification)` of the `NotificationViewController` controller that implements the protocol shown above. Below you 
-can find its source code.
+Then we can fill the UI with the notification content we receive in the `func didReceive(_ notification: UNNotification)` of the `NotificationViewController` controller that implements the protocol shown above. Below you can find its source code.
 
 ```swift
 import UserNotifications
@@ -64,9 +54,7 @@ class NotificationViewController: UIViewController, UNNotificationContentExtensi
 }
 ```
 
-Now to test our controller and our new notification UI, we can create a local notification. We will use some data taken 
-from the nasa photo journal. We will create a `NasaLocalNotificationBuilder` that contains all the notification creation logic. This is 
-the final result.
+Now to test our controller and our new notification UI, we can create a local notification. We will use some data taken from the nasa photo journal. We will create a `NasaLocalNotificationBuilder` that contains all the notification creation logic. This is the final result.
 
 ```swift
 import UserNotifications
@@ -75,7 +63,7 @@ class NasaLocalNotificationBuilder {
     private let notificationCenter: UNUserNotificationCenter = UNUserNotificationCenter.current()
     private var notificationActions: [UNNotificationAction] = []
     private var notificationContent = UNMutableNotificationContent()
-    
+
     func setActions() -> NasaLocalNotificationBuilder {
         notificationActions.append(
             UNNotificationAction(identifier: "view",
@@ -89,7 +77,7 @@ class NasaLocalNotificationBuilder {
         )
         return self
     }
-    
+
     func setCategory() -> NasaLocalNotificationBuilder {
         let notificationCategory = UNNotificationCategory(identifier: "NasaDailyPhoto",
                                                           actions: notificationActions,
@@ -99,7 +87,7 @@ class NasaLocalNotificationBuilder {
         notificationCenter.setNotificationCategories([notificationCategory])
         return self
     }
-    
+
     func setContent() -> NasaLocalNotificationBuilder {
         notificationContent.title = "Your Nasa Daily Photo"
         notificationContent.body = "Long press to see you daily nasa photo"
@@ -122,7 +110,7 @@ class NasaLocalNotificationBuilder {
         ]
         return self
     }
-    
+
     func build() {
         let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 5, repeats: false)
         let request = UNNotificationRequest(identifier: "NasaDailyPhoto",
@@ -133,8 +121,7 @@ class NasaLocalNotificationBuilder {
 }
 ```  
 
-Then we can call the notification builder in the main controller of the app `ViewController` to generate the 
-notification.
+Then we can call the notification builder in the main controller of the app `ViewController` to generate the notification.
 
 ```swift
 class ViewController: UIViewController {
@@ -149,15 +136,12 @@ class ViewController: UIViewController {
 }
 ```
 
-Now we have to go back in our notification content extension and set some attribute in its `info.plist`. In 
-particular we have to set:
+Now we have to go back in our notification content extension and set some attribute in its `info.plist`. In particular we have to set:
 
-* `UNNotificationExtensionCategory` to the notification category that we want to customize. In our case we use 
-`NasaDailyPhoto`, the value we previously set in the builder
-* `UNNotificationExtensionDefaultContentHidden` to hide the standard notification content when the user long press 
-the notification.
+* `UNNotificationExtensionCategory` to the notification category that we want to customize. In our case we use `NasaDailyPhoto`, the value we previously set in the builder
+* `UNNotificationExtensionDefaultContentHidden` to hide the standard notification content when the user long press the notification.
 * if needed it is possible also to set the `UNNotificationExtensionInitialContentSizeRatio` to a value different than
- 1 to customize the aspect ration of our notification.   
+ 1 to customize the aspect ration of our notification.
 
 We're ready to test our implementation. Below you can find a video with the final result of our implementation.
 

_posts/2018-09-18-refactoring-if-chain-of-responsibility.md

@@ -12,57 +12,35 @@ seo:
 authors: [francesco_bonfadelli] 
 ---
 
-*In this post my colleague [Francesco Bonfadelli](https://www.linkedin.com/in/fbonfadelli/ "Francesco Bonfadelli") 
-will show you how to transform a nested if structure into a chain of responsibility.*
+*In this post my colleague [Francesco Bonfadelli](https://www.linkedin.com/in/fbonfadelli/ "Francesco Bonfadelli") will show you how to transform a nested if structure into a chain of responsibility.*
 
 ---
 
-In this post I am going to describe a step by step process used to transform a nested if structure into a chain of responsibility. 
-The purpose of this operation is to make the code easier to read, thus to change without introducing errors. 
-We will also get for free a structure that will be able to apply a more generic set of rules than the one defined at the beginning.  
-The code of this post is based on a piece of code used to satisfy a real business need, 
-we just removed the business related details.
+In this post I am going to describe a step by step process used to transform a nested if structure into a chain of responsibility. The purpose of this operation is to make the code easier to read, thus to change without introducing errors. We will also get for free a structure that will be able to apply a more generic set of rules than the one defined at the beginning.  
+The code of this post is based on a piece of code used to satisfy a real business need, we just removed the business related details.
 The language used is java.
 
-#### The process in short  
+#### The process in short
+
 * Flatten the if structure into a flat sequence of `if` clauses
 * Extract each condition and the related action into a single class
 * Create a common interface for all the extracted conditions
 * Put all the conditions into a list
-* Loop over the list and return the first action for which the condition is satisfied 
+* Loop over the list and return the first action for which the condition is satisfied
 
 #### The need  
-It seemed a normal day of work when one of our managers called a meeting 
-to inform us of a very urgent feature that should be put in production 
-within 2 days.
-So, as it usually happens in this case, between the deriving chaos and the tons of alignment 
-meetings that continuously interrupted us, 
-we produced a code that basically "worked", but it was a bit chaotic. 
-Luckily we were able at least to write the tests.
-So, once we put in production the feature, we decided to immediately refactor the piece of code. 
-
-#### The process  
-We are going to see a step by step refactor of a specific class 
-that transforms the if-nested structure into a chain of responsibility.
-
-We are not going to change the tests because they work as an acceptance test for our use case. In an ideal world, 
-with a lot of time available, 
-we would also write the tests of all the classes we are going to extract and simplify the current test. 
-But, you know, we are not in an ideal world 😅.  
-The idea behind this refactor is to proceed with small steps, 
-possibly using the IDE functionality (I used IDEA which is very good at it), 
-and run the tests after every operation.
-Also, after each step there is a commit, not only to allow everyone to follow the evolution of the code through the commits, 
-but also to allow us to simply use ```git checkout .``` in case of errors, in order to come back to the previous working version. 
-All of this, allows us to keep the code strictly under control and avoid to introduce bugs during the refactoring.
-I will use the diff syntax to show the differences between some pieces of code. 
-Please keep in mind that I will use it in order to highlight *only the main differences* 
-between one commit and the other and it won't be the exact diff you can get with git.
+
+It seemed a normal day of work when one of our managers called a meeting to inform us of a very urgent feature that should be put in production within 2 days. So, as it usually happens in this case, between the deriving chaos and the tons of alignment meetings that continuously interrupted us, we produced a code that basically "worked", but it was a bit chaotic. 
+Luckily we were able at least to write the tests. So, once we put in production the feature, we decided to immediately refactor the piece of code.
+
+#### The process
+
+We are going to see a step by step refactor of a specific class that transforms the if-nested structure into a chain of responsibility. We are not going to change the tests because they work as an acceptance test for our use case. In an ideal world, with a lot of time available, we would also write the tests of all the classes we are going to extract and simplify the current test. But, you know, we are not in an ideal world 😅.  
+The idea behind this refactor is to proceed with small steps, possibly using the IDE functionality (I used IDEA which is very good at it), and run the tests after every operation. Also, after each step there is a commit, not only to allow everyone to follow the evolution of the code through the commits, but also to allow us to simply use ```git checkout .``` in case of errors, in order to come back to the previous working version. All of this, allows us to keep the code strictly under control and avoid to introduce bugs during the refactoring. I will use the diff syntax to show the differences between some pieces of code. Please keep in mind that I will use it in order to highlight *only the main differences* between one commit and the other and it won't be the exact diff you can get with git.
 
 #### The initial code
-Here you can find the code we were not very proud of. 
-In particular, I report the nested if structure, which is the part we are going to refactor.
-([Source code](https://github.com/bonfa/IfRemovingARealUseCase/blob/a6681dd088d06244878e0527e87b4c6b5bbfd50d/src/main/java/it/fbonfadelli/hand_baggage/HandBaggageInformationFactory.java))
+
+Here you can find the code we were not very proud of. In particular, I report the nested if structure, which is the part we are going to refactor. ([Source code](https://github.com/bonfa/IfRemovingARealUseCase/blob/a6681dd088d06244878e0527e87b4c6b5bbfd50d/src/main/java/it/fbonfadelli/hand_baggage/HandBaggageInformationFactory.java))
 
 ```java
 public class HandBaggageInformationFactory {
@@ -99,14 +77,13 @@ public class HandBaggageInformationFactory {
 ```
 
 #### The execution
+
 ##### 1. Flatten the if structure
 
 The idea here is to transform the nested if structure into a flat sequence of `if` clauses in order to isolate
 and explicit each single condition.  
-To do so with very small steps, we are going to remove the `else` part of each `if` clause, by transforming 
-such part into an `if` clause whose condition is the negation of the original one.
-In the following piece of code, you can notice how the outer if-else has become a couple of `if` clauses, 
-one for the original condition `flight.isOneWay()` and the other one with the opposite condition `!flight.isOneWay()`
+To do so with very small steps, we are going to remove the `else` part of each `if` clause, by transforming such part into an `if` clause whose condition is the negation of the original one.
+In the following piece of code, you can notice how the outer if-else has become a couple of `if` clauses, one for the original condition `flight.isOneWay()` and the other one with the opposite condition `!flight.isOneWay()`
 ([Source code](https://github.com/bonfa/IfRemovingARealUseCase/blob/a49340d05153074158cc59c130de6875276a92ab/src/main/java/it/fbonfadelli/hand_baggage/HandBaggageInformationFactory.java))
 
 ```diff