StructureFlow

structureflow

Hunting Exploits by looking for the Author’s fingerprints: Graphology of an Exploit

Learn how to use the Michelson programming language and write smart contracts on Tezos (Please check first Part 1 and Part 2) In this new installment of our series about Michelson language, we are going to crank it up a notch! In the last parts, we were having a quite simple stack and doing some basic manipulations, adding elements, removing them, duplicating them, etc. However, one of the powers of smart contracts is access-control: you can request your smart contract to verify if the person sending a request is allowed to modify the storage. If they are allowed, they can continue performing their operation. If they are not, the execution of the smart contract stops and all subsequent code is ignored. Unlike Ethereum smart contracts, smart contracts on Tezos do not modify the storage at any point in the execution of the transaction. The new storage is returned at the end of the execution if everything went well. This makes smart contracts on Tezos extremely secure: Michelson will make sure that everything is executed as it should before modifying the storage. Solidity will modify the storage and hope there will be no problem down the road 😊 In this article, we are going to write a smart contract that verifies that the sender of the transaction is allowed to modify the storage. If they are, we are going to concatenate the string they provide with the string in the storage. If they are not, the contract will just stop executing and return an error. The Michelson code The whole code of the smart contract is available in the Jupyter notebook binder. After navigating to the page and waiting a minute for the Michelson kernel to load, select MichelsonTutorial-Demo4.ipynb to see the code. As for the last lesson, you can see the inline code or run the code step-by-step. Let’s have a look at the inline code: It is amazing how much power such a small piece of code packs 😅 The storage looks different this time: it contains a pair with an address on the left side and a string on the right side. We are going to use the address in the storage to compare it to the sender’s address and give/refuse access. You probably recognized a few opcodes that were introduced in the previous lessons: DUP, CAR, PAIR, NIL, etc. There are also new instructions: DIG, SENDER, IFCMPEQ, FAIL, etc. No worries, we are about to see what they do. As usual, you are free to play with the step-by-step code in the Jupyter notebook so you can get a better understanding of what the code does and how it modifies the stack at each step. Step-by-step execution Now let’s go line by line and see what the code does! First, a pair containing the provided parameter and the storage is pushed onto the stack: DUP We want to duplicate the first element of the storage. As you are probably beginning to understand, this is a normal step to separate the parameter from the storage when you need both in two different elements: CAR Remember CAR? It takes the pair at the top of the stack and extracts its left value: DIP { CDR ; DUP ; CDR } This one is a very interesting and useful instruction! You can see that the instruction is made of two parts: the DIP part and the part between curly braces. The DIP instruction “protects” the element of the stack that it refers to. If there is no number after DIP, it will protect the first element on the top of the stack. You can also use DIP 2 or DIP 10 according to the number of elements. The DIP instruction is followed by some code between curly braces that will affect the element below the element protected by the instruction. As such, if you write DIP 0 { code }, it would be as if you wrote code and if you write DIP 1 { code }, as if you wrote DIP { code }: The code between curly braces should have no secret for you: it will extract the right part of the pair (CDR) which is also a pair, duplicate it (DUP) and extract its right part (CDR): DIG 2 Here is another very useful instruction! The DIG instruction moves an element to the top of the stack and is always followed by a number which indicates the index of the element you want to bring to the top (remember that the index starts at 0 in Michelson, so “element 2” will actually be the third one from the top): CAR Now, we have our storage on top of the stack and we can continue working with it. We want to extract the address saved in the storage to compare it with the sender’s address. The CAR instruction will get the address that is located in the left part of the storage pair: DUP You may be wondering why we need to duplicate the address we have just extracted from the storage. When we are going to compare this address with the sender’s address, they will both be removed from the stack. As we want to keep the address in the storage for the next transaction, we copy it now and keep a copy that we will save in the storage later: SENDER Another new opcode! SENDER pushes the address that initiated the current transaction on top of the stack. There is a subtle difference in Tezos smart contract between two instructions: SENDER and SOURCE. SENDER will be the address that created the current transaction, which means that if your smart contract receives a transaction from another smart contract, SENDER will be that smart contract address. SOURCE is always an implicit account address (i.e the account from which the very first transaction was initiated). In this case, it doesn’t matter much, but it can be important in other situations: IFCMPEQ {} { FAIL } Welcome to your first conditional structure in Michelson 👏🏻IFCMPEQ stands for “IF CoMPare EQual” and will tell you if the two values on top of the stack are equal. Note that the two values have to be of a comparable type and of the same type. After the IFCMPEQ instruction, you can see two blocks, each surrounded by curly braces. If the result of the comparison is true, the code in the left block will be executed. If it is false, the code in the right block will be executed. The only thing we want to do here is to make sure the two addresses are the same, so we want to make the contract fail if they are not. We are not going to run any code if they are the same, the contract will just continue its execution on the next line. The FAIL opcode will cease the execution of the contract and return an error. After the comparison is done, the two values that were at the top of the stack are removed: DIP { SWAP ; CONCAT } Another DIP instruction! We verified that the user who sent the transaction is allowed to alter the storage, so we can concatenate the string they provided with the one that’s in the storage! First, we want to protect the address at the top of the stack that we keep for later to save it in the new storage. The DIP instruction will just do that. Next, we want to reorder the two strings that we have in our stack to have “Hello ” before “world”. This is a job for the SWAP opcode. Once they are in the right order, we can concatenate them with CONCAT. Because we used DIP and put the next two instructions between curly braces, the code will ignore the first element of the stack and work with the ones below: PAIR I guess you are more familiar with the last steps of smart contracts in Michelson now! Remember the very first step, we had a storage made of a pair containing an address on the left and a string on the right. You have to recreate the same kind of setup to exit your smart contract. It will be very easy because we have now an address followed by a string in our stack! Using the PAIR instruction, we create a new pair whose left element is the element at index 0 on the stack and whose right element is the one at index 1: NIL operation This instruction should have no secret for you now! We push an empty list of operations on top of our new storage: PAIR This is now the end of the transaction. We create a new pair containing a list of operations (which is empty here) and the storage (a pair with an address and a string): When the stack only contains a pair with a list of operations and the storage, we are done and the execution can end successfully 🥳 You can also visualize the whole process of the execution of the smart contract in this video: Conclusion This ends Part 3 of our tutorial about Michelson language. It introduced a few new instructions that will be extremely useful in your smart contracts: DIP, DIG, IFCMPEQ, FAIL, SENDER, etc. You now have a better understanding of the general flow of a smart contract written in Michelson, how the different elements move and work with each other. The conditional structures are a very powerful tool to check the data entering the smart contract through transactions, for example, if the sender is allowed to perform an action, if the right amount of tezzies has been sent, etc. DIG and DIP are also essential instructions as we were restricted to the very top of the stack in the previous tutorials, but these instructions allow us to manipulate elements deeper in the stack. In the next tutorial, we will continue exploring the capabilities of Michelson, introduce new opcodes and dive into control flow and domain-specific data types. Stay tuned! Learn how to use the Michelson programming language and write smart contracts on Tezos (Please check first Part 1 and Part 2 ) (Please check first Part 1 Part 1 and Part 2 Part 2 ) In this new installment of our series about Michelson language, we are going to crank it up a notch! In the last parts, we were having a quite simple stack and doing some basic manipulations, adding elements, removing them, duplicating them, etc. However, one of the powers of smart contracts is access-control: you can request your smart contract to verify if the person sending a request is allowed to modify the storage. If they are allowed, they can continue performing their operation. If they are not, the execution of the smart contract stops and all subsequent code is ignored. Unlike Ethereum smart contracts, smart contracts on Tezos do not modify the storage at any point in the execution of the transaction. The new storage is returned at the end of the execution if everything went well. This makes smart contracts on Tezos extremely secure: Michelson will make sure that everything is executed as it should before modifying the storage. Solidity will modify the storage and hope there will be no problem down the road 😊 In this article, we are going to write a smart contract that verifies that the sender of the transaction is allowed to modify the storage. If they are, we are going to concatenate the string they provide with the string in the storage. If they are not, the contract will just stop executing and return an error. The Michelson code The whole code of the smart contract is available in the Jupyter notebook binder . After navigating to the page and waiting a minute for the Michelson kernel to load, select MichelsonTutorial-Demo4.ipynb to see the code. As for the last lesson, you can see the inline code or run the code step-by-step. Jupyter notebook binder MichelsonTutorial-Demo4.ipynb Let’s have a look at the inline code: It is amazing how much power such a small piece of code packs 😅 The storage looks different this time: it contains a pair with an address on the left side and a string on the right side. We are going to use the address in the storage to compare it to the sender’s address and give/refuse access. You probably recognized a few opcodes that were introduced in the previous lessons: DUP , CAR , PAIR , NIL , etc. There are also new instructions: DIG , SENDER , IFCMPEQ , FAIL , etc. No worries, we are about to see what they do. DUP CAR PAIR NIL DIG SENDER IFCMPEQ FAIL As usual, you are free to play with the step-by-step code in the Jupyter notebook so you can get a better understanding of what the code does and how it modifies the stack at each step. Step-by-step execution Now let’s go line by line and see what the code does! First, a pair containing the provided parameter and the storage is pushed onto the stack: DUP DUP We want to duplicate the first element of the storage. As you are probably beginning to understand, this is a normal step to separate the parameter from the storage when you need both in two different elements: CAR CAR Remember CAR? It takes the pair at the top of the stack and extracts its left value: DIP { CDR ; DUP ; CDR } DIP { CDR ; DUP ; CDR } This one is a very interesting and useful instruction! You can see that the instruction is made of two parts: the DIP part and the part between curly braces. DIP The DIP instruction “protects” the element of the stack that it refers to. If there is no number after DIP , it will protect the first element on the top of the stack. You can also use DIP 2 or DIP 10 according to the number of elements. The DIP instruction is followed by some code between curly braces that will affect the element below the element protected by the instruction. As such, if you write DIP 0 { code } , it would be as if you wrote code and if you write DIP 1 { code } , as if you wrote DIP { code } : DIP DIP DIP 2 DIP 10 DIP DIP 0 { code } code DIP 1 { code } DIP { code } The code between curly braces should have no secret for you: it will extract the right part of the pair ( CDR ) which is also a pair, duplicate it ( DUP ) and extract its right part ( CDR ): CDR DUP CDR DIG 2 DIG 2 Here is another very useful instruction! The DIG instruction moves an element to the top of the stack and is always followed by a number which indicates the index of the element you want to bring to the top (remember that the index starts at 0 in Michelson, so “element 2” will actually be the third one from the top): DIG CAR CAR Now, we have our storage on top of the stack and we can continue working with it. We want to extract the address saved in the storage to compare it with the sender’s address. The CAR instruction will get the address that is located in the left part of the storage pair: DUP DUP You may be wondering why we need to duplicate the address we have just extracted from the storage. When we are going to compare this address with the sender’s address, they will both be removed from the stack. As we want to keep the address in the storage for the next transaction, we copy it now and keep a copy that we will save in the storage later: SENDER SENDER Another new opcode! SENDER pushes the address that initiated the current transaction on top of the stack. There is a subtle difference in Tezos smart contract between two instructions: SENDER and SOURCE . SENDER will be the address that created the current transaction, which means that if your smart contract receives a transaction from another smart contract, SENDER will be that smart contract address. SOURCE is always an implicit account address (i.e the account from which the very first transaction was initiated). SENDER SENDER SOURCE SENDER SENDER SOURCE In this case, it doesn’t matter much, but it can be important in other situations: IFCMPEQ {} { FAIL } IFCMPEQ {} { FAIL } Welcome to your first conditional structure in Michelson 👏🏻 IFCMPEQ stands for “ IF CoMPare EQual ” and will tell you if the two values on top of the stack are equal. Note that the two values have to be of a comparable type and of the same type. IFCMPEQ IF CoMPare EQual After the IFCMPEQ instruction, you can see two blocks, each surrounded by curly braces. If the result of the comparison is true , the code in the left block will be executed. If it is false , the code in the right block will be executed. IFCMPEQ true false The only thing we want to do here is to make sure the two addresses are the same, so we want to make the contract fail if they are not. We are not going to run any code if they are the same, the contract will just continue its execution on the next line. The FAIL opcode will cease the execution of the contract and return an error. FAIL After the comparison is done, the two values that were at the top of the stack are removed: DIP { SWAP ; CONCAT } DIP { SWAP ; CONCAT } Another DIP instruction! We verified that the user who sent the transaction is allowed to alter the storage, so we can concatenate the string they provided with the one that’s in the storage! DIP First, we want to protect the address at the top of the stack that we keep for later to save it in the new storage. The DIP instruction will just do that. DIP Next, we want to reorder the two strings that we have in our stack to have “Hello ” before “world”. This is a job for the SWAP opcode. Once they are in the right order, we can concatenate them with CONCAT . Because we used DIP and put the next two instructions between curly braces, the code will ignore the first element of the stack and work with the ones below: SWAP CONCAT DIP PAIR PAIR I guess you are more familiar with the last steps of smart contracts in Michelson now! Remember the very first step, we had a storage made of a pair containing an address on the left and a string on the right. You have to recreate the same kind of setup to exit your smart contract. It will be very easy because we have now an address followed by a string in our stack! Using the PAIR instruction, we create a new pair whose left element is the element at index 0 on the stack and whose right element is the one at index 1: PAIR NIL operation NIL operation This instruction should have no secret for you now! We push an empty list of operations on top of our new storage: PAIR PAIR This is now the end of the transaction. We create a new pair containing a list of operations (which is empty here) and the storage (a pair with an address and a string): When the stack only contains a pair with a list of operations and the storage, we are done and the execution can end successfully 🥳 You can also visualize the whole process of the execution of the smart contract in this video: Conclusion Conclusion This ends Part 3 of our tutorial about Michelson language. It introduced a few new instructions that will be extremely useful in your smart contracts: DIP , DIG , IFCMPEQ , FAIL , SENDER , etc. DIP DIG IFCMPEQ FAIL SENDER You now have a better understanding of the general flow of a smart contract written in Michelson, how the different elements move and work with each other. The conditional structures are a very powerful tool to check the data entering the smart contract through transactions, for example, if the sender is allowed to perform an action, if the right amount of tezzies has been sent, etc. DIG and DIP are also essential instructions as we were restricted to the very top of the stack in the previous tutorials, but these instructions allow us to manipulate elements deeper in the stack. DIG DIP In the next tutorial, we will continue exploring the capabilities of Michelson, introduce new opcodes and dive into control flow and domain-specific data types. Stay tuned!

Using the Michelson Programming Language to Write Smart Contracts on Tezos [A How-To Guide] - Part 3

Introduction: Flow of the program depends on the value of the various variables we use in our code. Depending on the values of the variables in our program, we navigate the flow of execution as we needed / required. For example if we are using any collection types, it is hard to perform logic when the collection is modified or changed. i.e when new items are added, deleted, or modified. We can still manage this kind of scenarios in many ways. One of them is using Notification-Centre, To notify us whenever the change occurs in property value. But if want to check on many properties in our code, this (using Notification Centre) way lead us to heavy chunk of code, to call for all those properties we need to check on. The Other way which is better In this kind of scenarios is (also Apple using this in its libraries a lot) known as (Key Value Observing), which is also directly related to another powerful mechanism called (Key Value Coding). KVO KVC Note: Any property we want to observe for changes must be KeyValueCoding (KVC)complaint. Both of these KVO & KVC, provide an efficient way to write our code. Now lets get started with KVC and then KVO. KVC: is a form of coding that allows you to access an object’s properties indirectly, using strings to access them instead of the property’s accessors or instead of accessing the variables directly. To enable such mechanism, your classes must comply to the NSKeyValueCoding informal protocol. (OR) KVC Key-value coding is a mechanism for accessing an object’s properties indirectly, using strings to identify properties, rather than through invocation of an accessor method or accessing them directly through instance variables. Ex: class Profile: NSObject { var firstName: String var lastName: String var customProfile: Profile } If we want assign the values for the above declared variables, in the class init() or somewhere in the class file, normally we do like the following: self.firstName = “Robert” self.lastName = “Stark” With KVC; we do like the following: self.setValue: “ Robert ” for key: “ firstName ” //self.setValue: Any for key: key/KeyPath self.setValue: “ Stark ” for key: “ lastName ” To retrieve the values of KVC properties we use like the following: let robertLastName = self.value( forKey: “ lastName ” ) The above KVC working way is like working with Dictionaries in swift. Right? Here, In KVC; Instead of directly , or using (#If available) , we are doing in a way simply values to assigning the values to properties setter methods of objects assigning keys/keyPaths. So we use keys and values , this technique is called Key Value Coding(KVC). every class that is defined in the framework and that inherits from conforms to the protocol. Note: There is protocol known as NSKeyValueCoding informal protocol , which is compulsory to work with KVC . Our classes must be confirmed to this protocol, in order to use KVC & KVO . NSObject confirms to this protocol. So Foundation NSObject NSKeyValueCoding What is a key & KeyPath ? Key : simply “ Key ” specifies a single property, the one we want to set a value or get one from . So its name should be the same as the property’s name. Ex: self.setValue: “ Stark ” for key: “ lastName ” KeyPath : A KeyPath is formed with the dot-syntax by following the substrings, so it is not a single word/string. Key-path represents all the properties of an object, which comes in the way until to reach the desired value/property . Ex: var myProfile: Profile self.setValue: “ Baratheon ” for key: “ myProfile. customProfile.lastName ” KVC : Here, we are going to create a single view application, to work with the KVC & KVO. This project has two example projects, but the one we are exploring here is not related with any UI. The other one is updates a UILable on ViewController’s view when the text changes. The Project link will be shared at the bottom, so you can explore easily yourself. First, create a single view application in swift To use KVC our classes need to confirm to NSKeyValueCoding protocol. So by confirming to NSObject, we can achieve this step. UIViewController is already confirms to this NSObject, so We can call the methods from this protocol without any setup. In Xcode, In your project create a new swift file, with the name Children with NSObject as a base class(Children inherits from NSObject). Then In that class file, declare two properties named ‘ and ‘ by placing ‘ ’ keywords at the front of the declaration_._ So why do we need to do this??? name’ age’ @objc dynamic → In swift, there are many keywords/ attributes to help the compiling, runtime specifications, access controlling etc. Ex: @escaping, @available, etc. Likewise, It also defines a range of declaration modifiers, to modify the declarations of properties/class-members. For example, by marking a class declaration with the‘ keyword, we inform the compiler that the class cannot be subclassed. This allows the compiler to make a number of optimisations to increase performance. ‘ is also a declaration modifier we use in swift. final’ dynamic’ , is one of the cool features in Objective-C. It simply means that the Objective-C runtime decides at runtime which implementation of a particular method or function it needs to invoke. For example, if a subclass overrides a method of its superclass, dynamic dispatch figures out which implementation of the method needs to be invoked, that of the subclass or that of the parent class. This is a very powerful concept. Dynamic dispatch Swift uses the Swift runtime whenever possible. The result is that it can make a number of optimisations. While Objective-C solely relies on dynamic dispatch, Swift only opts for dynamic dispatch if it has no other choice. If the compiler can figure out at compile time which implementation of a method it needs to choose, it wins a few nanoseconds by opting out of dynamic dispatch. Swift runtime chooses other options, such as and , over whenever possible. It does this to increase performance.Static and virtual dispatch are much faster than dynamic dispatch. Even though we are talking nanoseconds, the net result can be dramatic. Many features we have come accustomed to are only possible because of the dynamic Objective-C runtime, including Core Data and Key-Value Observing. static virtual dispatch dynamic dispatch Dynamic Dispatch By applying the ‘ declaration modifier to a member of a class, you tell the compiler that dynamic dispatch should be used to access that member. dynamic’ By prefixing a declaration with the ‘ keyword, the declaration is implicitly marked with the attribute. The attribute makes the declaration available in Objective-C, which is a requirement for it to be dispatched by the Objective-C runtime. dynamic’ objc objc ‘ declaration modifier can only be used for members of a class. Structures and enumerations don't support inheritance, which means the runtime doesn't have to figure out which implementation it needs to use. dynamic’ So to use KVC & KVO in swift, for the properties we want to observe in KVO we need to declare them with @objc dynamic keyword. Now, we have two properties in our class, Initialise/define them in initialiser method. Children Now in ViewController class file, declare three Children Instances like the following: First we use of ‘ object. In the viewDidLoad() method, we initialise the child1 object, and then assign the values to its properties. child1’ If you print the‘ objects properties like name and age you will get the assigned values in result. child1’ Now, we will use the KVC methods to do the same thing. In the above snippet, In the first couple of rows we set the desired values to both properties using the method. observe the key strings are the same to the properties’s names. setValue:forKey: Next, we perform the exact opposite task. We extract the values out of the properties using the method, and we assign them to two local variables. And then we printed the values in the console. The result is the same as the previous one. valueForKey: Note: If we give keys different to the property names, The app will crash. When writing KVC-compliant code it’s really important to take care so the key strings actually match to the property names, otherwise the app will simply fall apart. This is not a case when dealing directly with properties, as there’s no chance to do any mistake on their names; the compiler would throw an error in such a case which would drive us to fix it. With all the above, we have managed to see how to write KVC-styled code, and how to set and get values using keys. In the next part we will complete the project. working with key-paths: Now go to the Children class, and add the following property. @objc dynamic var child: Children? in the method. Now, add the next lines that initialise the related objects and assign their initial values: viewDidLoad In the above snippet, in the first couple of rows we just initialised the‘ _child2 ’_object and its ‘ property. Next we set the values to the properties and of . For the property of , we used key-path to set the values. Observe closely. we can retrieve the values to check if the assignment was successful: Uncomment the print statements for that. child’ name age child2 child child2 Now we will see what if the child of the child has a child too… If you want to check the values/result use the print statements for the above snippet. So far, we learned how to write KVC complaint code using keys and key-paths. Next we will learn Observing the Property’s value changes: KVO : Here we will see what actions should be taken in order to be able to track down changes on properties. First of all, let me introduce you as a list the steps needed to implement KVO: 1. The class of which you want to observe its properties must be KVO compliant. That means: The class must be KVC compliant according to what we have already seen in the introduction and in the previous section. The class must be able to send notifications either automatically, or manually (we will see more about that later). 2. The class that will be used to observe the property of another class should be set as . observer 3. A special method named should be implemented to the observing class. observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) Let’s see everything one by one. The most important thing when we want to observe for changes of a property, is to our class observe for these changes. This is done more or less with as with the casual notifications ( ), but using another method. This method is the make NSNotifications addObserver(<#T##observer: NSObject##NSObject#>, forKeyPath: <#T##String#>, options: <#T##NSKeyValueObservingOptions#>, context: <#T##UnsafeMutableRawPointer?#>) Here we observe the value changes for and properties of a object. So in viewWillAppear() method, add the observers for the child1 object. name age child1 The parameters the above method accepts are: : This is the observing class, usually the object. addObserver self : I guess you can understand what’s this for. It is the string you used as a key or a key path and matches to the property you want to observe. Note that you specify here either a single key, or a key path. forKeyPath : an array of values. options NSKeyValueObservingOptions : This is a pointer that can be used as a unique identifier for the change of the property we observe. Usually this is set to or . We’ll see more about this later. context nil NULL Now that we have made our class able to observe for any changes in the above two properties, we must implement the method. Its implementation is mandatory, and it has one great disadvantage. That is the fact that is called for every KVO change, and if you observe many properties then you must write a lot of statements so as to take the proper actions for each property. However, this can be easily overlooked as the benefits of the KVO are greater than this limitation. observeValueForKeyPath:ofObject:change:context: if The above method will be called every time change in the value of properties which are added to the observer. Here by key-path parameter, we printed the new and old values of the name and age properties. To test this functionality, wire-up an action for a UIButton to your viewController, and in that action method add the following lines of code: Super! After we have set a new value to the and properties of the object, we received the notification, and the messages we asked for to be displayed were shown on the debugger. As you see, both the previous and the new value are included in the dictionary. name age child1 From the dictionary you can extract any value you want (if needed), but the most important of all is that it’s super-easy to be notified about changes in properties. change add the following lines of code in the button action method and run the program. If you observe the result, we receive two notifications regarding changes to the property. But that seems confusing, because even though we know the object that each notification belongs to, programmatically we can do nothing to determine the object that sent the notification. So, how do we face that, and how can we programmatically be a 100% sure about the object that the changed property belongs to? age The answer to the above question is one: We will make use of the argument of the method. I have already mentioned before that the purpose of the context is to uniquely identify a change on a property, so it’s the best tool we have at our disposal. context addObserver(<#T##observer: NSObject##NSObject#>, forKeyPath: <#T##String#>, options: <#T##NSKeyValueObservingOptions#>, context: <#T##UnsafeMutableRawPointer?#>) Here I defined two contexts for each child1 and child2: Note that the context value for each observed property must be a global variable, because it has to be accessible from both the and the methods. addObserver… observeValueForKeyPath… Now modify the code in child1 and child2 add observer methods, by passing the context parameter. And then we need to modify the observe method as well like the following: This way we can identify the changed property with help of passed context parameter. So we managed to programmatically specify each changed property. Lastly and before we reach at the end of this chapter, it’s also quite important at some point to remove the observers you add. There is not a recipe on where you should do that. For instance, in many cases it would be useful to do that in the , after you have handled a received notification. In other cases, you should do so upon the dismissal of a view controller. Generally, it’s up to your application’s structure the decision you will make about that. In this example, we will do it in the method. Here it is: For observeValueForKeyPath:ofObject:change:context: viewWillDissapear: child2, I removed observer in the above snippet. Automatic and Manual Notifications By default, the system sends a notification every time a property gets changed when you observe using KVO. This is suitable in most cases, however there are times that we don’t want to get a notification once a change has happened, but after a bunch of changes have taken place in multiple properties or at a later time. Thankfully, iOS SDK provides us with some quite convenient methods that gives us control over the notifications, so we can manually send them whenever it’s actually needed. Before we get into more details, let me just say that using the method you’ll see right next is not mandatory. On the contrary, you may implement it if and when it is really necessary. Getting into the point now, in order to control the notifications that are sent upon property changes, you must implement the _automaticallyNotifiesObserverForKey:_class method. The parameter it accepts is a string representation of the key of the property for which you need to control the notification, and it returns a boolean value. In case that you don’t want a notification to be sent after the observed property’s value has been changed, then the method must return false. In any other case, you should let iOS decide about the notifications. In practice, let’s suppose that we don’t want a notification to be posted when the property of the class get changed. With that in mind, here’s the implementation of that method in the class name Children Children In the clause, we call the same method using the class in order to let iOS handle all the keys that we haven’t explicitly added here, and the value that we get back is the one that we return at the end. else super If you run the app at this point, you’ll find out that no message regarding the name changing is appeared on the debugger. Of course, this is what we desire, so we’ve managed to achieve our goal. But, have we really done it? Well, as you understand by returning false in the above method for the specific key, we’ve only managed to stop the relevant notifications from being sent. And of course, this doesn’t mean manual notifications, it means no notifications at all! In order to send a notification when we decide so, we must use two other methods. These are the and the . When using them, the must be called first, then the new value must be assigned to the property, while the should be called at the end. To test the manual actions, add these lines in the action method of viewcontroller. willChangeValueForKey: didChangeValueForKey: willChangeValueForKey: didChangeValueForKey: If you run the app now, the message regarding the name change is appeared on the debugger, and that means that we’ve sent the notification manually with success! Actually, the notification is sent after the method is invoked, therefore place that method wherever you feel appropriate for receiving notification. didChangeValueForKey: That’s what exactly we have been expecting from the app! As you can see, we’ve managed to control the notification sending point, and all that with a little effort! Note that between the and the methods, you can have more than one property values assigned. willChangeValueForKey: didChangeValueForKey: The and the methods are not mandatory to be used as shown above. They can be implemented in the class (or in your own class) as well. willChangeValueForKey: didChangeValueForKey: Children Please click for the project describing above tutorial. here References: http://michael-brown.net/2017/swift-and-kvo-context-variables/ https://www.appcoda.com/understanding-key-value-observing-coding/ https://cocoacasts.com/key-value-observing-kvo-and-swift-3 https://www.ralfebert.de/ios-examples/swift/property-key-value-observer/ https://blog.scottlogic.com/2015/02/11/swift-kvo-alternatives.html If you like my tutorials please follow me on . You can contact me through or accounts. medium my-twitter linkedIn Thanks for reading. Will get better soon with more tutorials. See you!!!

KVO & KVC In swift

KVO y KVC en rápido

The Building Blocks of UI/UX: How Atomic Design Transforms Your Workflow

As continues to evolve, new coding patterns and programming practices are constantly being developed. One of the most significant advancements in recent years is the concept of Inversion of Control (IoC). IoC is an important concept for software developers to understand because it allows them to create more modular and maintainable code. software engineering In simple terms, Inversion of Control is a design pattern in which the control of an object’s behavior is inverted or moved outside of the object. This allows developers to more easily change an object’s behavior without having to modify the object itself. This concept is essential for creating flexible, decoupled systems that can be easily maintained. In this article, I’ll cover the benefits of IoC, how it works, and provide examples of how IoC can be used in real-world scenarios. This article is intended for individuals who are looking to enhance their software development skills and gain a deeper understanding of IoC. Understanding Inversion of Control Inversion of Control (IoC) is a that helps manage the flow of objects in a software application. In traditional programming patterns, a component knows about and controls the instantiation of its dependencies. In IoC, this control is inverted, and a container takes on the responsibility of managing the dependencies, allowing for greater modularity, flexibility, and testability. design pattern When answering “What is inversion of control?”, the best way that I can think about explaining this is with the Single Responsibility Principle. If you have a component that does something, as soon as it’s also responsible for creating its dependencies… it’s doing multiple things. Now, I get that in real life code isn’t always perfect but I like thinking about moving in this direction as being positive. So if we want to keep a component from doing at least one more thing, we can offload the creation of dependencies. That’s someone else’s job. We just know what interfaces/APIs we want to code against, but someone else can give us the implementation of those. What About That Dependency Injection Thing? One popular implementation of IoC is through dependency injection (DI), where dependencies are injected into a component instead of being constructed within it. This approach enables a component to be decoupled from its dependencies, allowing for greater flexibility in the design of a system. With DI, components can contain any dependencies, which can be supplied by a configuration file or the container itself. Typically this is done via constructor parameter passing, but this can also be done in other ways. I opt for constructors. If you have , you’ll know that I like using a popular library called Autofac to do a lot of this work for me. checked out some of my articles Benefits of Inversion of Control IoC has many advantages for software engineering, including: Reducing code complexity: Consider the amount of duplicated code for having many separate locations create their dependencies… Making code more testable: This is because we can alter the concrete implementations of the dependencies of the system we’re testing. Improving code maintainability: This is because we can make changes to a dependency without having to potentially break open another class (i.e. just pass in a different implementation if needed) With IoC, components can be developed and tested in isolation, allowing for easier debugging, and making it simpler to change specific dependencies without having to change the entire application. Drawbacks of Inversion of Control Despite its many advantages, IoC is not without challenges. One notable disadvantage is that while IoC can be beneficial in large applications, it may add unnecessary complexity to smaller projects. I have a hard time avoiding setting up a DI container in almost any project now. As soon as I don’t need to pass parameters in via constructors manually… the better. Additionally, excessive usage of IoC can make code difficult to understand, especially for developers who are not familiar with IoC or DI implementations. Which… I mean… Yeah. I admit that I go overkill with its usage. provides many features that are well-suited to implementing IoC, such as delegates and attributes. Let’s take a closer look at some code examples to see how IoC concepts are implemented in C#. C# Applying IoC to Real-World Scenarios Inversion of Control (IoC) can be applied to various scenarios and is not limited to specific or frameworks but can be used to create more modular, testable, and maintainable code. In this section, we’ll discuss some real-world scenarios where IoC might come in handy and how it can be applied to them. programming languages Benefits of IoC in Web Application Development Web application development is a common area where developers can apply Inversion of Control. IoC can benefit web applications by making the code organized, scalable, and testable. Web applications can range from small-scale websites to large-scale enterprise applications. Regardless of the size of the application, developers can incorporate IoC principles to create more modular and maintainable code. The benefits of IoC in web application development include: – One of the main principles of IoC is Dependency Injection (DI), which reduces tight coupling between components. DI makes the code more modular, meaning the code can be tested and changed more efficiently. Dependency Injection – Web applications often grow in complexity over time. Applying IoC principles can help simplify the complexity and increase the application’s scalability. Scalability – IoC promotes unit testing since it allows for testable, decoupled code. Better testability results in better code reliability. Testability The Code Before IoC can be applied to web application development in many different ways, but here is an example of what the code might look like before: public class UserRepository
{
  private readonlyILogger _logger;

  public UserRepository()
  {
    _logger = new SpecificLogger();
  }
}

public class UserService
{
  private readonly UserRepository _userRepository;

  public UserService()
  {
    _userRepository = new UserRepository();
  }
} After some inversion of control, we’re passing dependencies in via the constructor: public class UserRepository
{
  private readonlyILogger _logger;

  public UserRepository(ILogger logger)
  {
    _logger = logger;
  }
}

public class UserService
{
  private readonly UserRepository _userRepository;

  public UserService(UserRepository userRepository)
  {
    _userRepository = userRepository;
  }
} However, in this code example, UserService is dependent on UserRepository. This can become problematic depending on a specific implementation instead of the interface, making it harder to test and change the code. But, applying a DI framework, we can refactor the code into something like this: services.AddTransient<IUserRepository, UserRepository>();
services.AddTransient<IUserService, UserService>();
services.AddTransient<ILogger, StructuredLogger>(); This refactoring injects the dependency into the constructor, making the code modular and testable. The UserService can now be tested without having to supply a real UserRepository. Common Pitfalls and Challenges When implementing Inversion of Control (IoC), there are several common pitfalls and challenges that developers may face. Understanding these challenges and strategies to overcome them can make the implementation process smoother. Overcoming Dependency Injection Pitfalls and Challenges One of the biggest challenges when implementing IoC is understanding dependency injection, a key component of IoC. There are several common pitfalls faced when using dependency injection, including: Overcomplicating the dependency injection container: Developers may overcomplicate the dependency injection container, making it difficult to maintain and debug. Managing dependencies between different frameworks: Dependency management between different frameworks can be challenging, adding complexity to the implementation process. Difficulty managing the scope and lifetime of objects: It can be difficult to manage the scope and lifetime of objects within a dependency injection container. To overcome these challenges, developers can take the following steps: Simplify the dependency injection container: Keep the dependency injection container simple and maintainable to avoid unnecessary complications. Ensure dependencies are properly scoped and registered: Properly scoping and registering dependencies ensures that the correct dependencies are injected. Use tools and frameworks designed for dependency injection: Several tools and frameworks can assist with dependency injection, such as Microsoft Dependency Injection and Autofac. By understanding these challenges and taking action to overcome them, developers can implement IoC more effectively in their software development practices. Answering What is Inversion of Control In this article, we discussed the concept of Inversion of Control (IoC) and how it is revolutionizing modern software engineering. We also examined some real-world scenarios where IoC can be applied and how it helps in making the code more modular, testable, and maintainable. We understood the difference between traditional programming patterns and IoC and explored the benefits and challenges associated with it. IoC is an important concept for any software engineer to understand and incorporate into their workflow. It helps in creating smoother, cleaner code and makes it easier to maintain and update. By implementing IoC, you’ll be contributing to a more efficient and effective development process while ensuring that the code is better and more secure. Whether you are working with web applications or other software projects, incorporating IoC will benefit you with more manageable and testable code. I personally can’t turn back after getting on the inversion of control bandwagon! If you’re interested in more learning opportunities, and ! subscribe to my free weekly newsletter check out my YouTube channel Also published here.

Beginner's Guide to Inversion of Control

The Definitive Crash Course on Serverless with AWS: Centralized logging with Kinesis and Lambda

When I started Redux I was shocked by the number of discussions and “best practice” you could find online about it, but it didn’t take too much time to understand why: is not very opinionated about the way of structuring a project around it, and this can lead to some annoyance when you’re trying figure out what kind of structure suits better your style and your project. learning Redux In this post I’d like to share some information on my journey to achieving a comfortable Redux project structure. This is not an introduction/tutorial, a bit of knowledge of Redux is required to understand it entirely. Also, apart from redux-sagas (which can be replaced by redux-thunk or by your favorite library for handling asynchronous actions), I won’t use any external Redux library/utility. Hope you find it interesting! First stop: grouping files by “type” When I started using Redux I studied the from top to bottom and I organized my project this way: official doc This structure is promoted by the and in my opinion it is still a pretty solid option.The main drawback of a structure like is that even adding a small feature might end up in editing several different files.For example adding a field (that is updated by an action) to the product store means that you’ll have to: official Redux repository examples add the action type in types/product.js add the action creator in actions/products.js add the field in reducers/product.js And it doesn’t end here! When the app grows you’ll probably add other directories to the mix: So, after introducing in my project I relized that it was becoming too hard to maintain and I started looking for alternatives. redux-saga A different approach: grouping files by feature An alternative to the project structure above consists in grouping files by feature: This approach has been promoted by various interesting articles in the React community, and it is used in . one of the most common React boilerplate At first glance this structure seemed reasonable to me because I was encapsulating a component (the container), its state (the store) and its behavior (the actions) in a single folder, following the React’s component concept.After using it in a bigger project though I discovered that it is not all sunshine and rainbows: if you’re using Redux you’re probably doing it for sharing a slice of store across you’re app… and you can see easily that this clashes with the encapsulation concept promoted by this structure.For example dispatching an action from the product container might produce side effects on the cart container (if the cart reducer reacts in some way to the action). You must also be careful not to be caught in another conceptual trap: don’t feel forced to tie a slice of the Redux store to a container, because otherwise you’ll probably end up using Redux even when you should have opted for the simple setState. Ducks to the rescue After the small adventure of grouping by feature I went back to my initial project structure and I noticed that using Sagas for handling the asynchronous flow has the interesting side effect of turning 90% of your action creators in one-liner: const login = (email, password) => ({ type: LOGIN_REQUEST, email, password }) In a situation like this, having a dedicated file for each action creator, action type and reducer seemed a bit overkill, so I decided to try out the “Ducks” approach. is a proposal for bundling reducers, action types and actions in the same file, leading to a reduced boilerplate: Ducks The first time I adopted this syntax I fell in love with it.It's clean, it removes a lot of unnecessary boilerplate and you can easily add an action or a field to the reducer by changing a single file. Unfortunately though, using ducks started showing quickly its limits because exporting individually every single action creator and action type has some nasty side effects. In bigger containers you’ll end up having a huge list of imported actions that are only used one time (for feeding mapDispatchToProps): import { signup, login, resetPassword, logout, … } from ‘ducks/authReducer’ You won’t be able to pass to mapDispatchToProps directly all the actions of a duck. Using won’t work, because you’ll end up importing the reducer too. import * as actions You’ll waste a super precious variable name just for passing it to mapDispatchToProps.You won’t even be able do something like because you already defined the variable by assigning it to the action creator imported from the duck. const { login } = this.props login In bigger sagas you’ll end up using a lot of different actions without knowing their context (you’ll have to scroll to the top imports every time). Customizing the ducks My solution to the above issues is simple: instead of exporting individually action types and action creators I group and export them inside a types and actions object: If you structure the ducks this way you’ll be able to import the actions easily inside your components: Now you may ask: what if I need to dispatch actions of different ducks inside a component?Well, you can do something like this: I know, it’s a bit uglier, any alternative solution is welcome! Originally I opted for the name actionTypes/actionCreators instead of types/actions , but after a bit I refactored to the latter: the first option was too verbose for my taste. P.S.: From now on, for simplicity, I’ll keep referencing the files containing actions/reducers/types as “ducks”, even if in my current projects I have them in the “reducers” folder. Selectors In my opinion selectors are the most overlooked feature of Redux.I must admit that I started used them a bit too late, but reading opened my eyes and I begun viewing selectors as interfaces that expose the store to the containers. this tweet of Dan Abramov Need to display a list in a certain order? Define the selector. getProductOrderedByNameselector Need to get a specific element of a list? Define the selector. getProductById Need to filter a list? Define the selector. getExpiredProducts By following this strategy most of the selectors you define will be strongly tied to a specific reducer, so the right place for defining them is the file containing the reducer itself). Sometimes you’ll need to define more complex selectors that handle the input from different slice of the store.In this situations I put them in reducers/index.js . The sagas Sagas are really powerful and testable, but being used for managing asynchronous actions and side effects make it a bit hard to reason on how to add them to your project structure.My suggestion is to start grouping sagas that are triggered by a single redux action in the same action domain.This means that if you have a reducer that handles the authentication in , you can create , containing the sagas that are triggered by , and so on… ducks/auth.js sagas/auth.js authTypes.SIGNUP_REQUEST authTypes.LOGIN_REQUEST Sometimes thought you’ll need to trigger the same saga from with different actions. In this case you can create a more generic file containing this kind of sagas. For example this simple saga for React Native shows an alert when it intercepts an error: If the generic file (in this case i called it ) grows too much you can always refactor it later being more specific. sagas/ui.js Another thing worth nothing is that in I have a file that links the take…instruction of every saga to its implementation: sagas/index.js In this way I’m able to track down every saga easily by associating the saga with action types that trigger it. Conclusion That’s it! Here is my current project structure (as I anticipated above I renamed the “ducks” folder to “reducers”): I know there’s still room for improvements, and this is probably the main reason that made me publish this post: tips and critics are welcome! Edit #1: Where do you place actions/types that are not tied to a specific reducer? In most of my project I have one (or more) generic duck that handles this kind of actions. For example if the project is small enough I simply create , a duck file containing 1) all the actions creators and action types that are not reducer specific and 2) the state of the ui/app: ducks/app.js Please keep in mind that these ducks may not need a reducer: they can contains just action creators and action types. Edit #2 A more explicit approach Some comments on Reddit and Twitter hinted that ducks may promote the idea that the relation between actions and reducers is , when it actually is . I agree with them. In fact (in my opinion) a structure that follows the Redux philosophy even more than the one I showed you would be the following: many:1 many:many I still prefer to use the customized ducks though, and when I have actions that are not tied to a reducer (or the opposite) I adopt the solution I explained above in the edit #1.In the end you might need to test different structures by yourself for finding the tradeoff between explicitness and comfort that suits better your style and your project. Thanks to and . @mxstbr joshwcomeau Credits and useful links by Mark Erikson React/Redux Links list in a pull request of the awesome Ignite boilerplate repository (which uses a structure just like the one I showed you) This discussion , because he inspired me to write this post and because we had an interesting discussion about Redux that you can find Steve Kellock here , because all the stuff he posts is super-interesting and well written (and thanks for Redux too! :P) Dan Abramov , a bit outdated but I’ll try update it as soon as possible This baby boilerplate is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories https://upscri.be/hackernoon/

Stories, News & Mentions about STRUCTUREFLOW

Structureflow’s Stories on HackerNoon