Hello Solidity, hello Ethereum

According to official Solidity docs is a contract-oriented, Solidity is a high-level language for implementing smart contracts. It was influenced by C++, Python and JavaScript and is designed to target the Ethereum Virtual Machine (EVM).

Alright, let’s talk about Solidity’ syntax and its features. Basically I’m mention the following subjects: Contracts, Types of variables, Math operations, Functions, Arrays, Structs and Events.

Let’s start

A contract is the fundamental building block of Ethereum applications — everything goes inside the contracts. This is very similar to Java, commonly all the code is encapsuled in ‘Class’.

First important thing you need to learn is how Solidity handles variables. Solidity is a statically typed language, which means that the type of each variable. Once you start coding variables and functions inside you Contract file, you need to understand Solidity has two types of variables: state and local. State variables are permanently stored in contract storage - into the Ethereum blockchain, it may cost some ‘gas’ in case you try to modify them. Local variable you can modify them freely but remember you will loose their value right after the context/scope change - they are not stored.

Booleans bool: The possible values are constants true and false.

Integers int / uint: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.

Address address: Holds a 20 byte value (size of an Ethereum address). Address types also have members and serve as a base for all contracts.

Members of Addresses balance and transfer: It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the transfer function.

Fixed-size byte arrays bytes1, bytes2, bytes3, …, bytes32. byte is an alias for bytes1.

Dynamically-sized byte array bytes: Dynamically-sized byte array. string: Dynamically-sized UTF-8-encoded string.

String Literals They are written with either double or single-quotes (“foo” or ‘bar’). They do not imply trailing zeroes as in C; “foo” represents three bytes not four. As with integer literals, their type can vary, but they are implicitly convertible to bytes1, …, bytes32, if they fit, to bytes and to string.

Math Operations

Solidity offers the following math operations (it is almost the same as in most programming languages):

Addition: x + y Subtraction: x - y, Multiplication: x * y Division: x / y Modulus / remainder: x % y Support an exponential operator (i.e. “x to the power of y”, x^y):

Structs

Sometimes you need a more complex data type. For this, Solidity provides structs:

`struct Person { uint age; string name; } Structs allow you to create more complicated data types that have multiple properties.

Events

Events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be ‘listening’ for certain events and take action when they happen.

Events are inheritable members of contracts. When they are called, they cause the arguments to be stored in the transaction’s log - a special data structure in the blockchain. These logs are associated with the address of the contract and will be incorporated into the blockchain and stay there as long as a block is accessible (forever as of Frontier and Homestead, but this might change with Serenity). Log and event data is not accessible from within contracts (not even from the contract that created them).

Further details

I’d recommend this article Ethereum Smart Contract Best Practices for beginners.

Architecture Components – let's make Android great again

Google I/O 2017 brought a new package of outstanding news. In my point of view, one of the most relevant news were Architecture components, a new bunch of libraries that help developers design apps with testability, maintainability and clean code.

Room

This is my favorite library of Architecture Components, surely. Room is an object mapping library that let the code clean and collaborate with SQL queries. Furthermore, the library provides SQL queries validation compilation time, annotations and observables for database changes. I knew this today would come, a day that Google will release a library for persistence such Apple offer for iOS (Core Data). Hereafter I have no doubt Room will be a reference for the persistence layer although there are tons of similar libraries such as ORMLite, Active Android or GreenDAO.

ViewModel

• Provide data for fragment/activity;
• Independent of View: configuration changes don’t affect ViewModel;
• Similar to an usual presenter however the retention/loading is built-in;
• Retention happens through FragmentManager and HolderFragment;

Live Data

it is responsible for listen and propagate data changes: an observable data holder It allows broadcasting of data changes all over the architecture layers taking into account all system issues eg. memory leaks.

Lifecycle Owner - Lifecycle

It allows the creation of lifecycle-aware components which are able to adjust itself automatically according to the current lifecycle. This feature is possible because Lifecycle owner associates a class to the lifecycle via an abstract class called getLifecycle().

Further Details

I recommend this project which Google team implemented samples of Architecture Componentes and this video from Google I/O.

Introduction to Reactive Programming with RxJava

RxJava is a Java VM implementation of ReactiveX, a library for composing asynchronous and event-based programs by using observable sequences. It is used for reactive programming which I like to refer as “programming with asynchronous data streams” or “programming waiting for something happens to trigger your code” or “programming to react undetermined events”

I’m gonna be straightfoward because this topic it is a well known case that you only learn by doing. Basically, this is how it works: A Subscriber subscribes to Observable, then Observable calls Subscriber.onNext() for any number of items, if something goes wrong here is Subsciber.onError() and if all finishes fine, here is Subscriber.onCompleted().

The foundations

Subscribers -> It listens to the events/items;

Observables -> It emits events/items - This class provides methods for subscribing to the Observable as well as delegate methods to the various Observers. It is necessary to trigger/listen/activate/start the observables otherwise they don’t do anything;

Operators -> Functions responsible for manipulate observables. It can applyed along other operators and it has seveval goals: creation, combination, transformation, filtering, etc;

Schedulers -> It manages the work with thread pools via Executors (java.util.concurrent);

Transforming Streams with operators

As it was said before, operators can manipulate observables. There are plenty of them and it is really important to know how/when use them. Here is the most popular RxJava operators:

Further details

I totally recommend this talk by Jake Wharton, an outstanding developer and a reference in opensource projects. Another option is watch this video but don’t forget to practice, try to implement what it is suggested in the video.

Some useful GIT commands

Git is a version control system that is used for software development and other version control tasks developed by Linus Torvalds in 2005. As a distributed revision control system it is aimed at speed, data integrity, support for distributed and non-linear workflows.

git config

Sets configuration values for your user name, email, gpg key, preferred diff algorithm, file formats and more.

git branch -a

Lists existing branches, including remote branches.

git branch -d [branch-name]

Deletes the specified branch

git push origin –delete [branch-name]

Deletes the specified branch from remote

git stash

Temporarily stores all modified tracked files

git stash list

Lists all stashed changesets

git stash pop

Restores the most recently stashed files

git stash drop

Discards the most recently stashed changeset

git reset [commit]

Undoes all commits afer [commit], preserving changes locally

git reset –hard [commit]

Discards all history and changes back to the specified commit

git show

Shows information about a git object.

git grep

Lets you search through your trees of content for words and phrases. Example: git grep “www.google.com” – *.js

Model View Presenter (MVP) on Android

The MVP pattern allows separate the presentation layer from the logic, so that everything about how the interface works is separated from how we represent it on screen. Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views. First thing to clarify is that MVP is not an architectural pattern, it’s only responsible for the presentation layer . In any case it is always better to use it for your architecture that not using it at all.

Check this simplified MVP example for Android

Model: This is the well known model, present in many of the most common patterns and use cases. It represents the world we are working with, every real world element that our app should know how to represent. Both the View and the Presenter are aware of this model and they know how to use its properties and methods (the view doesn’t really need to know the model and originally shouldn’t but it’s a tradeoff that avoids the need to have setter methods for every field that we want to update).

View: As stated before, views are our Fragment and Activity classes that we are using, they are able to alter the UI as we need and they need to receive structured data from a source in order to populate themselves. This layer shouldn’t know anything else about the obtention of the data, we made it as simple as we could.

Presenter: This layer, introduced here, is implemented with native java code meaning it doesn’t need to know whether it’s used in an Android application or a web service. How does this work with our structure previously described? Easy, what we are going to add to each view is a simple interface which defines the actions that any view using a specific presenter would need to do in order to populate itself with the data it provides. The presenter is responsible to act as the middle man between view and model. It retrieves data from the model and returns it formatted to the view. But unlike the typical MVC, it also decides what happens when you interact with the view.

References

• https://medium.com/mobiwise-blog/android-basic-project-architecture-for-mvp-72f4b33252d0#.gebnmc1rq
• http://antonioleiva.com/mvp-android
• http://hannesdorfmann.com/mosby/mvp/