This is the second year in a row that Tuenti showed the Google I/O Extended 2014 from our Barcelona office. Over 40 people met at our downtown office to enjoy the event and do a little networking.
This meeting allowed us to contact other developers and share our passion on “Google World”, as well as enjoy and comment the news introduced during the keynote in a relaxing environment with snacks and drinks.
We thank all the attendees and specially the Barcelona Google Developer Group. We are open to hosting user groups meetings and talks so, if you’re interested in organising a tech or design-related event, get in touch!
As every month, we hosted the 7th PHPMad meeting in the kitchen of our central Madrid office. Moisés Maciá talked about “Gestionando tu infraestructura con Ansible”. Ansible is an open-source software platform for configuring and managing computers. It combines multi-node software deployment, ad hoc task execution, and configuration management.
In addition to PHPMad, we are open to hosting other user groups meetings and talks so, if you’re interested in organising a tech or design-related event, get in touch!
Tuenti hosted the 8th Madrid MySQL User Group meeting where Keith Hollman presented Oracle's strategy and plans for MySQL for both the rest of 2014 and 2015 where Oracle will continue to support and improve MySQL suite.
After that he showed MySQL Cluster general overview and concepts and all the improvements that have been made to it in the last few versions.
Afterwards and with a nice cluster made of RPI a practical demo was done where we could see how MySQL Cluster behaves when a node goes down, or when the Management Node fail.
It was really good to see that Oracle keeps improving MySQL Cluster as it can be a really interesting product for some environments where Replication isn't an option.
If you are interested in organizing an event at our office, please contact us.
SmsRadar is the first open source library released by our Android team. This library has been implemented to listen to every incoming and outgoing SMS that the user’s device receives or sends. This Android library works for Android 2.X or higher versions.
SmsRadar has been implemented because intercepting incoming SMS is not a trivial task, if an Android developer wants to intercept an outgoing SMS he can use BroadcastReceivers because Android SDK allows you
to listen to SMS intent filter. But, what about incoming SMS? You can’t use BroadcastReceivers to implement this because there is no intent filter to listen to incoming SMS. Another option is to configure your application to work as an SMS native application, but this SDK feature is not available for all Android versions.
This Android library implementation is based on an Android SDK element called ContentObserver. To be able to listen to a native SMS database we have registered a ContentObserver implementation called SmsObserver to the native SMS ContentProvider. The following class diagram represents the main classes involved in this library.
The visible part of this library -from the library user's point of view- is:
To use SmsRadar developers have to register SmsRadarService into their AndroidManifest and start/stop SmsRadar library using two main methods available in SmsRadar class: “initializeSmsRadarService” and “stopSmsRadarService”.
SmsRadar is just the first Android library released by Tuenti. We will continue working to contribute to Android Open Source Community.
Have you ever gone into a view controller and had the same sensation as you have when you enter a room after a huge party? It happened to me more than once. The last I saw was more than 1.600 lines long. How can you find anything inside? How can you test it, refactor it, change it or add new features?
Making our View Controllers lighter makes our life happier. Our applications have long lifetimes and we will have to read the code we write a lot of times. The problem is that when we start to learn how to develop for the iOS platform using Apple’s examples, we get used to having a lot of things inside the VC classes. Business logic, database, view logic…
This post talks about how we can separate our view logic from the view controller.
First of all, create a class for the view. This class will contain all the details of the view and will be an abstraction for the VC. The interface of the view will consist of methods to change its state and a way or ways to retrieve information from it. That means that the VC is not coupled on how the view is implemented, only with the features it offers to it.
The view model is defined by the view and contains the information the view can show and/or modify. The view controller creates the view model and fills it with information that it knows how to retrieve from the model. Once created the instance is assigned to the view. The View Controller also subscribes to any property the view can change using KVO, usually on viewDidAppear (and unsubscribe to viewDidDisappear).
You need to have references that point to your subviews, all this UILabels, UITableViews or whatever objects you are using to create your interface. All of these are implementation details and shouldn’t be visible to the other classes. The best place to define them is using properties in the private interface of the view.
The XIBs are only a way to define your views not your VC. I think that’s an extended misunderstanding among developers. XIBs are an automated way to create our subviews and layouts. The view controllers use xibs to instantiate our views.
XIBs are a good way to write less code for interfaces, they are perfect to define the layout and the subviews used inside. You can connect the properties of the private interface with the instances of the subviews created by the xib using IBOutlets. At the interface builder you can specify the class of the view, this way the framework knows it has to create an instance of your concrete view subclass:
Your view has asynchronous events to communicate to the VC like when a user taps a button. This events can be sended to the VC using the delegate pattern as Apple do with other views like UITableView, UITextField...
The delegate should be defined in the .h file of the view because it is defining the events that the view can generate. The view will have a delegate property that the VC will be responsible to set. It can be set through the XIB or in the viewDidLoad method depending on your style and both works for testing purposes.
The views have plenty of asynchronous operations like showing an animation or asking for confirmation to the user. In these cases I use blocks. I think it’s preferable for readability, it gives you a feelling of continuity inside your code. Also an operation can be used in different places of your VC, and do different things for each case at the its completion.
This strategy is also useful for testing purposes. I can easily create a test double for the view with a fake implementation that only calls the block. That lets me test the view controller without messing around with sync issues simulating both cases, when the user confirms or not, depending on the test case.
I know that some of these practices seems to be against what are the standards from Apple. There’s no place at the Apple guideline where they say that separating your view from the view controller goes against the framework. Or that you have to define your IBOutlets in your VC. That works on small systems but when they grow and become more complicated you need to separate your responsibilities, and make your code readable and testable.
You can think that adding this level of indirection will make you a slower programmer. Of course that has a cost in time but once you are used to it, it doesn’t take that much time and the benefit in the future will make you more agile. You will feel that when reading your code, it will be faster to find what you are seeking.
You can read the extended and original version of this post here.