An open-source library to make Android’s action bar shine out

Posted on 4/01/2014 by Manuel Peinado, Mobile Apps Engineer

FadingActionBar is a library that helps developers implement a cool UI pattern: a picture occupies the top part of the screen, and the action bar is initially invisible. Once the user scrolls down to reveal more content, the action bar becomes opaque as the image disappears into the top of the screen. A picture is worth a thousand words:

It is fair to mention that I didn’t invent this pattern, I simply wrote the first open-source implementation of it. As far as I know it was introduced in the Play Music application about a year ago and then has been adopted by several other apps like Foursquare. My library has been just in the right place at the right time, when this pattern was growing really popular among the Android community, and it soon became successful. To be honest, its success caught me by surprise. At that time I had developed some other libraries that had not hit the 100 star mark on GitHub and I couldn’t even dream of ever having one that would reach 1000 stars. In fact I still cannot believe it!

In addition to the 1000-star milestone, I’m also proud to say that the library is currently used by several applications already in the Play Store, and that almost one year later people still add it to their new projects. In fact I get emails related to the library and new issues on Github almost every day, it’s hard to keep up with them.

Technically the library is not very complex, in fact I think I finished the first version in just a couple days. Then, I added some other improvements like ListView support (which is a bit buggy yet and I wish I had more time to devote to it) or WebView support. Another big improvement came with v3 a few months ago when I rewrote most of the library and added support for all action bar types (native, Sherlock and AppCompat) under a single project. Oh, and in case any test engineers from Tuenti are reading this, I have to admit that the library doesn’t have any unit tests. Sorry guys, I’ll do a better job next time!

Before I finish I would like to thank Android guru Cyrili Mottier because he wrote the blog post that made my library possible. If you are interested in knowing more about the way the library works internally, then his blog post is the place to go.

Engineering Across Platforms

Posted on 5/06/2013 by Erik Schultink, CTO

In the last year or so, we’ve been dealing with a big problem that many web 2.0 companies have also faced: Going mobile.

I’ve benefited from reading others’ thoughts on the subject, but we’ve learned quite a bit through our own experiences. I’ll describe where we’ve come from and the six big changes we’re making to be a more cross-platform company, from the perspective of engineering management. Hopefully you’ll find some of these lessons helpful for your team.

Web was our DNA
We were birthed in AJAX; our desktop web client was our flagship, in which we sought to produce a fast and rich user experience. It was built to leverage the most compelling techniques that Javascript, in the latest web browsers, could provide. Our JS experts were the rockstars in the company, prized by our recruiters. While we also built a simple, mobile version of the site, our intent was merely to give users a way to stay connected when they couldn’t access a “real” browser. I don’t believe we were alone in this approach..

In 2007-08, mobile was niche; it was utilitarian. Tablets were clumsy novelty toys. iPhones couldn’t run apps. There was something called WAP. Android didn’t exist. We saw mobile use cases like “entertain yourself on the bus”, “pull up the details about the event while you’re on the way”, “get notified when you’re tagged in a photo (with option to untag)”. It was basic - get stuff done, keep in touch - when no better alternative existed.

What we were wrong about was how quickly mobile app platforms would become “good enough”. Not just good enough for those basic utility cases - but for just about everything. Sure a full size screen might give you larger photos and a keyboard might help you write messages more quickly - but people were more willing to accept slightly smaller photos and slower typing than we anticipated.

Where this left us, in 2010, was with an organization of about 150 people in development-related roles (product, design, qa, engineering, etc) geared towards our flagship JavaScript-based client. We had Android, iOS, J2ME, and Blackberry development ongoing - but these were not where the balance of our people or attention lay. This neglect showed in the tools and processes we had to support development on these platforms.

What we had to change
I’ll go through each in detail, but let me summarize the changes that we’re making to transform our engineering organization for this challenge:
1. Architecture of clients and services
2. Interdisciplinary, product-oriented project teams
3. “Core” client/framework teams that build base components and support project teams with expert-level advising and code review
4. Cross-platform training program
5. More code review

Architecture of Clients and Services
We started as a big monolithic web app. That legacy remains. What you experience on and is, in many places, a presentation/client layer that is quite tightly coupled to the backend data access/management layer that powers it. It probably will be for a long time.

These backend layers - and the communication between those layers and the html/javascript “client” - were built first and foremost for a web context. The assumption is that our client is running in a user’s modern browser, fully capable of making multiple, parallel AJAX calls to our servers over a network that is usually fast and reliable. Data structures, abstraction, logic, etc are all designed accordingly. Our mobile clients - where this assumption does not hold as well - were a special-case, communicating with our data layer via an API that is, in truth, something of a client itself. 

To improve things, we’re moving towards a more a more service-oriented architecture (SOA). Each backend component is a service, exposing a well-defined API. Those APIs are designed not just for “web” clients that happen to run in the same PHP process but also remote clients. To the extent we have any kind of mobile-client-specific “API” layer, it functions as an adapter, attempting to be agnostic of both the particular service and client between which it’s mediating. 

As we live in the real world, and have a massive set of products and services already running, most of our stuff doesn’t comply with this vision. But that’s where we’re moving.

Team Structure
We learned long ago that the best way to scale a product dev org was to have inter-disciplinary teams. The idea is that for all the typical work that might come the team’s way, they have, internally, someone with the skills to get it done. They probably don’t have “the best” person in the company to do a given task; that’s OK. The point is that they are empowered to execute within their area of product responsibility, with minimal external dependencies.

For web, this mostly worked. We had teams with frontend engineers, backend engineers, and usually a designer, QA, and PM. We eventually even eliminated the frontend vs backend distinction to encourage people to be generalists. While I acknowledge that in practice people tend to get tracked one way or the other, the principle is that everyone should have the knowledge to work up and down the stack. For the extreme expert work, we had some core framework teams (next section) that built core bits and could offer guidance to help people working on a product team, if they encountered something particularly esoteric.

We’re extending this same structure across our mobile applications. For each feature that a team owns, they own that feature in each of client applications. Therefore, to be empowered to execute independently, they must have someone with the capability to build for that client. We staff accordingly, trying to spread people with not only php/js knowledge across our teams, but with android and iOS knowledge as well. As we recognize that work for a specific platform will vary for a team overtime, we want our people to be generalists, with the knowledge to work across more than one platform and we have created a training program (described below) to try to expand this.  

Core Framework Teams
For a number of years, we’ve had core framework and infrastructure teams for the web. As with our project team model, we generalized this for other platforms by creating, for each client platform we build for, a “core” team to own that platform within Tuenti. 

These core teams aren’t the main people building features for the platform. Rather, they build the base architecture and shared components, maintain a standard developer tool set for the platform, and define best practices and code standards. Operationally, they advise teams building for the platform, review their code, and manage the final stages of the integration cycle for clients on the platform. 

For our service platform (based in PHP), we similarly have a “backend platform” team that owns this layer, and performs analogous functions for services as the other teams do for clients.

We were mostly web guys (and girls). While we firmly hold the belief that programming languages are mere tools - and a good engineer chooses the appropriate tool for the situation - we certainly recognize that building for web vs mobile is about more than syntax and language features. There are differences in paradigms: concurrency, memory management, connectivity, etc. While most of us touched on these things back in university, a lot of these issues were safely ignored in day-to-day web work. 

To change, we’ve introduced a cross-platform training programming to step people through building their competency in a new platform.
- Level 0 “Exposed” - we start people with self-guided reading and “get to know you” talks, to familiarize people with the platform.  This stage is aimed at giving you a flavor of the platform and background on mobile concepts, in preparation for more formal training.
- Level 1 “Set-up” is to give you a full, working environment of all our tools for the platform, a repo clone, and a very basic knowledge of our specific architecture. The idea is that, in principle, if told to fix a typo on screen 3 of the registration flow in the app, you could, after digging around for no more than an hour or two, get this done and commit your change back. We offer workshops led by experienced engineers to walk people through this.
- Level 2 “Capable” means you have sufficient understanding of the frameworks, app architecture, and tests to code a small changeset (bugfix, feature tweak) that will pass review. Engineers are assigned a mentor to help them, should they need any support in this.
- Levels 3+ “Comfortable” - at this point, you can do day-to-day work independently.  From there, it’s just increasing knowledge/comfort/productivity with the platform - tracked only for the purpose of balancing skills across teams to match the features they’re building.

More Code Review
We’ve practiced code review for a long time. However, I would say that it used to be more of an encouraged best practice than an institutionalized (required) step in our dev process. That’s had to change for several reasons:
- First, while we want to empower anybody to work on any client/service, we can’t have a free-for-all; a specific team still owns each component and needs awareness/approval over what’s being done (and how).
- Second, it’s a natural, organic way to train people, share knowledge, and have ongoing feedback flow between peers. These first two points mattered on web, but they matter even more when you multiply the clients each team must now worry about and the platforms on which a given engineer must develop.
- Third, compared to our web apps, our mobile integration process is heavier and we ship less often, which means the cost of a bad change reaching either 1) integration, or 2) production is much higher (as we can’t discover and fix/revert it in hours or less). I’ll describe the integration/release process for mobile a bit more below.

To become more rigorous and embed code review in our process, we’re becoming more disciplined in our use of JIRA to track work and Crucible to review code. 

Like any organization, we’re still a work in progress. Changing the expectations and culture of 150 people is hard.  While the target vision will undoubtedly change before we’re 100% there, I’ve tried to give you an idea of how we’re facing a more cross-platform world. 

I might follow up with some more details on specific topics. If you have any specific questions that you’d like me to address, feel free to ask them via Twitter or Quora.

Mobile Libraries that worked well for us and might work well for you too

Posted on 2/05/2013 by Alberto Gragera, Davide Mendolia and Nuria Ruiz.

It seems like there is a never-ending stream of micro libraries that can be used in all types of ways, so we thought we’d share the libraries we use on Here, we’ll explain why we chose them, what gaps we needed fill how they’re working for us.

The first thing we’d like to mention is this: If you are developing mobile web for a wide set of devices, the number of Javascript libraries you might need to use in the first version might be zero. Why? Because it’s possible that the mobile devices your users are using simply can’t execute Javascript, even if the devices say they can. And if when you are thinking about mobile devices you are only thinking “phones” your definition might be too narrow.

There is an awesome presentation about what constitutes a mobile device by yibu:

As they very well explain, “the most popular devices do not necessarily translate to the most used devices”. In Tuenti’s case, there are couple devices on the most used devices list that cannot execute Javascript at all. Also, number 4 on that very same list is the iPhone.

In order to be able to support users with fancy smartphones and also users with devices that cannot really execute Javascript (or render any fancy CSS), we decided to have two versions of the mobile site. A “basic” version for the so-called feature phones and a “rich” version for so-called smartphones. There also exists the possibility that someone is browsing m.tuenti with a smartphone using a browser like Opera Mini. In that case, regardless of how cool or awesome your phone is, you will see the “basic” version. Additionally, a very basic version of your website for mobile is very handy because it can be easily used by old desktop browsers like IE6. We currently redirect all our IE6 traffic (we still have a small amount) to the basic mobile version of our site. Since the “basic” version is really basic, IE6 works well (and fast!).

You thought this post was going to be about Javascript mobile libraries, right? It is, but in our opinion, it’s definitely worth emphasizing that you can do mobile without Javascript.

When picking libraries, we ideally like for them to be well maintained, have full webkit support (since our rich version is geared towards webkit-based browsers) and provide value for weight.

There are only three main things we were looking for in a mobile Javascript framework: DOM methods, ajax ground work (like serializing forms) and delegates support.#

Zepto provides all three but only for webkit browsers. We took some time to evaluate the feature gap to make Zepto support Windows Phone and, while it’s doable, it seems that Windows Phone browser functionality is still too up in the air to be worth it.

For example, Microsoft decided to name touch events in a way that was different from what the W3 recommended (W3C Candidate recommendation) and this means that the touch event layer would need to be abstracted away to account for these differences

There is also the issue with __proto__.  Zepto uses the __proto__ property to extend the object’s prototype and add functionality while maintaining a reference to the original constructor’s prototype#. __proto__ is a non-standard property, but it come with EcmaScript 6. Sadly, it’s supported for the majority of modern browsers except for IE, regardless of the version. If you use any of the inheritance models out there rather than the __proto__ property, then a good chunk of the Zepto library works (~180/200+ tests start to pass).

For the time being, we aren’t modifying Zepto in any way. We use it as is, and we decided to downgrade Windows Phones to the “basic” (without Javascript) version. Since the mobile landscape is ever-changing, we might need to revisit this decision in the near future if we get more Windows Phone users.

The other winner when it comes to mobile libraries is the widely used FastClick maintained by FT Labs.. It solves the delay issue with touch events and clicks#. Kudos to this team - although we found a small bug with iOS4 support, they were very proactive when we suggested a solution.

While in theory most modern webkits support query selector well, we found that that was not the case for some of the Nokias we support in the “rich” version. There is a whole world out there with the many flavors of wekbkit in Nokia devices. For those browsers that do not support querySelector, we also add sizzlejs to the mix.

More than on the desktop, on mobile it is important to reduce the number of requests as much as possible, so you want to be careful when bundling together the Javascript that changes at the same rate. That is, all libraries that constitute your Javascript framework could be bundled together. Assuming that they do not change much, once downloaded they would be cached “forever” (if your cache headers are done well, etc). The Javascript that pertains to your features can be bundled in a separate bundle that will be updated more frequently. While this implies you would be doing at least two requests at the beginning of a session, it also implies a bigger cache hit ratio over the life of your application since only one of the bundles is updated regularly.

Just like you can do on a desktop, you can also do dynamic downloads of Javascript from the client on a per feature basis. While this strategy works great on the desktop (and that is what we do on it does it not work so well for mobile because we want to reduce the number of requests as much as possible. However, we are still investigating approaches on Javascript loading on mobile and we’ll discuss our results in a future blog post.

BcnDevCon 2011: Security, Mobile and our Release Process

Posted on 11/30/2011 by Diego MuñozSenior Fronted Engineer

Two weeks ago we were platinum sponsors of the Barcelona Developers Conference 2011, spending three days assisting to developer and entrepeneur talks but also speaking on three different tracks.

The 17th I spoke about how Tuenti release workflow works, both from the development perspective and from a broader devops and testing one. I detailed some of the opensource tools we use, the reasons why and some bottlenecks or problems we’ve run into.

On the 18th our Backend Framework and Security Lead gave a talk about security: Common web attack vectors, how they work, how to prevent them and some specific countermeasures we apply.

And finally, on the 19th our Mobile Core Tech Lead gave an interesting talk about the evolution of Tuenti’s Mobile site, challenges you face when you build for such a broad and varied device segment and how we try to give the best experience on each of them.

More or less at the same time, Pedro Álvarez and Diana López from the Apps Platform team, gave a presentation at the Universidad de Alcalá de Henares, during the first national RITSI event on Agile Methodologies and Cloud Computing. Their talk: Tuenti, from idea to the web, was a great success.

Follow us