When your software development project starts struggling with tight deadlines or skill gaps, team augmentation might be the boost you need. But how do you know if it’s the right option for you? We explore the most common scenarios where this model can be a great asset.

With software development projects, the final goal is easy to define—a rounded, working, thriving digital product. However, to reach that goal, there are many different paths you can take. For example, you can choose between in-house software development vs outsourcing, which we’ve written about before. 

This time, we’re tackling a path that’s “neither here nor there.” It’s for those situations where you almost have what you need with your in-house team, but you’re missing that little bit of extra – be it more hands on deck, the right skill set, or the right level of expertise. 

Team augmentation is a cooperation model that gives you simple access to all of the above. It’s a great way to quickly scale your development capabilities without the long-term commitment and additional costs of hiring full-time employees.

How do you know that this is the right path for you? In this article, we’ll present some common scenarios where augmenting your internal team with additional members is a great option.

Let’s get the definition out of the way. Team augmentation is an outsourcing model where a company adds external talent to its existing software development team on a temporary, contractual basis. The added members integrate with your team and work solely on your project during all working hours. With this staff augmentation model, you get all the dedication and focus of an in-house development team but with limited duration and limited responsibilities. 

Team augmentation is your boost button on the way to product delivery. Whether you need to track down tech talent to fill specific skill gaps, meet strict deadlines, or resolve complex technical issues, it’s a plug-and-play solution that gets you to your goal hassle-free.

There are multiple benefits to team augmentation, and the model can be applied to all sorts of software development projects in all sorts of industries. With over two decades of experience in the agency business, we’ve learned to immediately recognize the situations when team augmentation is just the remedy a project needs to get to successful completion.

Here’s probably the most typical situation that calls for staff augmentation services: you’re looking at your product roadmap, you’re looking at your people and their availability, and you think, “OK, there is no way we are going to be able to pull this through.”

With good organizational skills and development culture, you can organize your project so multiple teams can work on it independently. This includes an app architecture that supports this (like Micro Frontends, for example), a smart git branching strategy, meticulous documentation, effective communication, and devoted project managers. With the right setup, you can easily assign a portion of feature development to a remote team. 

When you’re operating within a staff augmentation model, it’s essential to set the game rules in advance. You want full alignment on the coding standards and the course of the development project. The idea is to speed up the process with a staff augmentation model, not slow it down due to misunderstandings and misaligned practices. 

The added benefit of team augmentation is that this model allows you to maintain the quality of work. When you’re chasing deadlines, things can easily fly under the radar, especially with an overworked team. By bringing in skilled reinforcements, you maintain quality standards and have a better product on your hands. 

Sometimes, your increased workload is time-limited, and you’re aware of it. Maybe you’re building an additional feature or performing a complex database migration. There are many scenarios when project requirements dictate a rapid team upscale, but after the work is done, you’ll either have to downscale just as quickly or bench people.

Clearly, hiring is not the best option here. It can be time- and cost-intensive, not to mention that the lack of work likely to ensue can have a negative impact on your team’s morale. 

It is important to recognize situations where your development process has a short uptick. By leveraging staff augmentation services, you can easily scale your teams up or down. Need three more people to deliver the project? No problem; let’s upscale the team. The majority of the work is done, and the workload has decreased? That’s perfectly fine; we can downscale the team. 

How about this situation? You have an excellent development team that delivers on a daily basis, but something is missing. Maybe your current project involves a complex technical challenge they have no experience with. Maybe it’s a matter of specific technology; your team is killing it on the frontend, but you now need a backend wizard. 

You can have your team attend courses, study documentation and online tutorials, but this takes time and can never really replace hands-on experience. What you really need is an ace who will join your team and start delivering quickly and efficiently, taking those technical issues head-on. 

There’s no shame in admitting that sometimes, you don’t have what it takes in your current roster of people (maybe it’s even people skills that are missing – we’ve seen that, too). And this is where an experienced pair of hands or a fresh pair of eyes just might save the day. 

Sometimes, you want to grow your development team, but at the same time, you need things done. This will often happen to startups in the scaling phase, where it’s important to keep up with the project requirements for delivery while working on building internal teams at the same time.

Hiring full-time employees is a lengthy process; you need to find the right candidates, assess their technical skills, get them up to speed, achieve team cohesion, and as the old meme wisdom goes – ain’t nobody got time for that. 

Leveraging staff augmentation services can give you some breathing room here: Your outsourced team members will make sure those delivery tasks get done while you focus on building an in-house team for the long run. A remote team you can rely on in the early phase can save you from making any rash hiring decisions under pressure.

A great example of this scenario is our cooperation with Mara. With several outside factors at play, Mara had very strict deadlines for product launch. They knew they ultimately wanted an in-house team to work on their product, but there simply wasn’t enough time to build one. Our designers and developers worked alongside theirs, and as Mara’s internal capacities grew, we gradually downscaled our engagement. As a bonus, the arriving team members learned from existing ones and strengthened their skills in the process.

To do digital transformation in the insurance industry right, you need to know the industry. Drawing from two decades of experience, we present the key principles for building winning digital solutions in the insurance space.  

When we talk about digital technologies, innovation, and cutting-edge solutions, the insurance sector probably isn’t the first one to come to mind. With all the administration, regulations, and large product complexity, many consider insurance to be a very traditional business. 

In reality, nothing could be further from the truth. 

Digital transformation in the insurance industry is moving faster than a claims agent after a hail storm. Actually, the sector has been one of the first to digitize its systems to improve internal processes, make more accurate risk assessments, and inform product pricing.

However, with rapid advancements in digital technologies and changing consumer expectations, insurers can’t afford to just maintain the status quo. Customers expect more from their digital experiences. They want fast and smooth processes, intuitive interfaces, and complex interactions made simple.  

With over two decades of experience on projects focusing on digital transformation in insurance, we’ve come to learn some important principles for building digital products that customers love and businesses thrive on.

In general, digital transformation is about using technology to create new or improve existing business models by introducing digital innovation to processes, products, or services. 

An early example of digital transformation in the insurance industry is the use of scanners for digital document filing, as well as complex algorithms backed by historical data for shaping the prices of insurance premiums more accurately. This allowed insurance companies to become more profitable and better at risk management. 

Then, as the World Wide Web became more and more populated in the 1990s, insurance businesses started selling their products over the internet. This gave them a new source of revenue and also helped them increase customer loyalty and retention.

And today? The insurance industry is hardly imaginable without digital processes. Paperless document signing, online applications, instant quotes, fraud detection, fully digital insurance claim submission and processing, instant insurance, gamification, tracking devices in cars that monitor how a person is driving so that their premium can be adjusted accordingly… 

Building a great digital product that will be easily adopted by customers and bring success to a business takes more than tech expertise. Knowing the industry you’re building for allows you to shape that product so that it meets the needs of the market and effortlessly finds its place in it. 

When building for the insurance sector, these are the things to keep in mind.

Insurance apps have a very specific target audience. These are not the types of mobile apps users will interact with daily. On the contrary, they will tap that icon only when they need something.

This can make understanding your audience somewhat challenging as you won’t have ample opportunity to get to know their needs and expectations regarding digital experiences. 

Additionally, and this might come as a hard truth for insurance providers, they also don’t want to engage with your digital product more than that. 

This fact comes into play when you think about upselling your users with additional services. Sending them push notifications about new offers on a daily basis is probably not the best strategy. However, sending them a push notification about travel insurance once their location changes to another country? That could work out great.

We’re not talking about the band that loves heavy makeup, but a well-known principle in marketing, software engineering, and many other fields – keep it simple, stupid.

Insurance forms and contracts are usually very long and complex. Digitizing the process gives you an opportunity to simplify a complicated matter and position yourself as a leading digital service provider with forms that are easily understood by anyone.

When you decide to go down this road, don’t just transfer your paper forms to a digital format.

Think about the customer experience and presenting your data in an easily understandable way and only to the extent to which it is absolutely essential for the user. 

In the insurance sector, there is an important factor that works in favor of the service providers, and that is customer loyalty. Most users won’t go researching insurance companies each time their contract expires. It’s a hassle and a time-wasting task, especially for an average user who didn’t need to activate their insurance policies in the previous year. 

This definitely doesn’t mean that you can get comfortable and not worry about customer retention. On the contrary, invest in the relationships you have with your loyal customers to strengthen them.

And bear in mind that the loyalty described above only goes so far. After all, you’re operating in a heavily saturated and highly competitive market. Current trends show that the costs of switching insurance providers are going down as the ease of using digital products in insurance is going up.

It is just one of the reasons why insurers should make the UX of their digital tools an absolute priority. If your customer gets a more affordable insurance offer from a competitor with a beautifully designed app that lets them do everything in three clicks… they will be tempted to make a move despite years of loyalty.

With so many digital channels available to people nowadays, the sheer volume of customer data collected is increasing exponentially. This can be both a challenge and an opportunity for insurers.

Managing and storing this data efficiently and securely is, of course, a prerequisite. And with the data at their disposal, insurance companies can use advanced analytics to gain valuable insights that will help them shape new insurance products and services, form competitive prices, improve the user experience and their underwriting and claims handling processes. 

For example, a person who drives an eco-friendly car, mostly for commuting to work and weekend trips, could get an offer for comprehensive coverage with enhanced protection for commute-related incidents and roadside assistance for those weekend getaways. Throw in a discount for green vehicles and a safe driver bonus, which could be applied towards the premium or future renewals, and you have a perfect fit.

Insurance companies operate in a highly regulated environment and deal with sensitive customer data. By providing personal data through digital products, the users put their utmost trust in the insurance providers. That trust may come easily for established companies but know that it’s also painfully easy to lose.

Data breaches can cause immense damage. Obviously, there are financial losses, but the damage to an organization’s reputation is especially hard to recover from.  

Be very careful how you design your product, remember security plays a critical role, and bake it into every stage of the development process. If you don’t have the resources in-house, hire outside experts and test your insurance solutions thoroughly from a cyber security standpoint to make them bulletproof.

Insurance forms are notoriously difficult to read and understand. There’s no problem with this when you’re signing the contract; most users will do the usual next-next-I-agree dance. However, when they find themselves in a situation where they need to collect the insurance money, things can get complicated fast.

Design your insurance products so that you lead your customers by the hand and give them all the information they need, but not excess information. Format and compile your contracts in a way that a high school student with no experience would understand them. 

Your customers are not insurance experts – they just want to know that what’s precious to them is insured and safe. When there is an unfortunate event, you need to step in and step up. Help them in a way that they understand. 

For example, one of our banking clients, NLB, offers 24/7 video chat support, and we’ve integrated this feature into their mobile app. Imagine you’re traveling abroad, and you need to increase your credit card limit, but it’s 4 AM back home. That video chat will be a lifesaver.

Writing this article without touching upon the magic of artificial intelligence would be impossible in the year 2024, and the insurance business has some great use cases for AI products.

Most insurance providers have collected vast amounts of data in the past two or three decades. With the right tools, this data can be easily utilized for fraud detection, introducing new insurance products and offers to the market, automating routine tasks, providing a personalized experience, and educating their user base. 

But, remember the KISS principle. For starters, you can implement a nice AI-powered chatbot or a flow that would help the user pick out the best offer for their specific case. Maybe a completely personalized offer too?

Though no novice in digital transformation, the insurance industry is well-settled in its ways. Insurance products have carved their niche in the digital landscape, and groundbreaking changes don’t happen on a daily basis. It’s important not to get stuck in the setup that you have. 

Bearing in mind the above best practices, it might be helpful to connect with an external technology partner to support you on your business transformation journey. They can bring a new perspective to your business and introduce you to new ways and digital tools to challenge the status quo.

The second edition of Infinum Slovenia’s Business Breakfast event identified the main reasons behind project delays. Knowing what to expect, we all become better equipped to tackle potential issues.

Once there’s a product reaping success out in the market, nobody will think much about the hurdles that have been encountered on the way. However, hurdles are more common than you think, and one of the most common ones are project delays.  

The phenomenon of software development projects often running late and the reasons behind it were the main focus of the panel discussion held at Infinum Slovenia’s Business Breakfast – a brunch-style networking event for a select group of attendees from the local business community. The idea behind the event is to encourage honest and open discussion on various topics at the intersection of business and technology, even the not-so-comfortable ones.

The main guest of Business Breakfast’s second edition was Goran Golubović, the CIO of Deželna banka Slovenije, a bank with a long tradition and history and a wide network of 76 branches across Slovenia, and the president of the Information Technology Committee of the Bank Association of Slovenia. 

Speaking from 25 years of experience in digital transformation projects in the financial sector, Goran identified some of the most common pitfalls that are likely to push a project’s release date far from the client’s original expectations.

Goran Golubović has worked in managerial roles at a number of banks in the Slovene market and is a professor at the Rome Business School in Belgrade, leading the executive MBA module Managerial Data Science and Advanced Analytics. With a strong background in IT engineering and ample business experience, he was able to provide valuable insights into the subject in question.

When RecyclerView was introduced, we were amazed with all of the new possibilities. We could finally start using ViewHolders by defaults, simply switch between list or grid by using a different LayoutManager, define our own custom click listeners, and a lot more.

What was missing were some basic ListView features – empty view support for example, and this began to frustrate me. When I started working on a project where headers and footers with RecyclerView had to be used I knew it was the right time to do something regarding the problem.

I decided to write my own wrapper around RecyclerView and RecyclerAdapter. The wrapper needed to be as simple as possible and offer a limited set of functionalities, I envisioned it to mimic ListView and ArrayAdapter behaviors. I didn’t want to overcomplicate. We don’t want to save the world – we just want to speed up our development process.

That’s how MjolnirRecyclerView was born – and after a few tweaks and bug fixes, it’s finally ready to take its place in the hand of the lawful ruler of Asgard. It’s open sourced and available on Github.

Add the library as a dependency to your build.gradle

Define an adapter, which extends MjolnirRecyclerAdapter:

Include MjolnirRecyclerView in XML layout:

In your activity, set MjolnirRecyclerAdapter to MjolnirRecyclerView and populate it with data.

MjolnirRecyclerAdapter treats header and footer view as two different ViewHolders inside RecyclerAdapter, which are added to the MjolnirRecyclerView. At the moment, it supports only one header and footer.

Mjolnir offers full header and footer support for LinearLayoutManager (both vertical and horizontal), and GridLayoutManager.

Add an empty view to the RecyclerView and it will be automatically shown when items are set to the adapter.

You can also show empty view while the adapter is not set to the MjolnirRecyclerView, which is handy if you want to initialize adapter at some later point in the time.

DiffUtils is an awesome utility class introduced with Android Support library version 24.2.0. It can easily be used to calculate updates for RecyclerView adapter.

Simply add DiffUtil.Callback in adapter’s update method:

As DiffUtil is a blocking sync action, it’s executed on the background thread inside the MjolnirRecyclerAdapter by using a AsyncTask. As a result of this approach, you need to call cancel() method on your adapter when your activity or fragment is about to be destroyed so that the adapter is not updated if the screen has been destroyed.

Although RecyclerAdapter can be treated as an upgrade to regular ListAdapter, it’s missing some neat utility methods like add(), addAll(), reset(), remove(), set()… MjolnirRecyclerAdapter has full support for those methods.

MjolnirRecyclerAdapter defines OnNextPageListener interface listener, which is called when user scrolls to the end of the adapter data set. You can also define a minimum number of items to have below your current scroll position before onScrolledToNext() page callback is called.

There are some features we plan to add in future releases, like support for a custom number of header and footer views, loading views…

If you would like to get involved in developing new Mjolnir’s features, head forward to its official Github repository and make a pull request with a short description of your changes. Feedback and code contributions are very much welcome.

Last year, Facebook announced a series of changes to their developer platform and launched API v2.0. All Facebook apps have to start using this new API by the end of April 2015. As the big date is drawing near, a lot of questions are beginning to trouble developers.

With over a billion of users, Facebook is the most popular social network today. It has also become the largest open repository of personal user information. This data is publicly available via the Facebook API and we can use it to enhance the user experience of our mobile and web apps.

We can use it for:

Although the Facebook API is free of charge, we still need to adhere to platform policies. One of these is that the old Facebook API will officially become deprecated and we’ll need to switch to the new one.

There are a lot of important differences between API v1 and API v2:

The most important changes are connected to the permission management. Every app which asks for more than public_profile, email and user_friends permission needs to be reviewed by Facebook.

The user_friends permission has undergone many changes. You’ll no longer be allowed to obtain the friend lists of your users. This permission has been completely refactored and will now return only the list of the user’s friends who are using your Facebook app. Also, all friend_* permissions have been removed. This means that it’s no longer possible for an app to see data from your user’s friends. You can see this data only if those friends have also logged into the app and granted permission for the app to see that data.

Also, a large number of permissions have been completely removed. You can see the full list here.

After the deadline, all Facebook apps will automatically be migrated to API v2. This could potentially create a lot of problems for developers and end users. Facebook officially states that users who will use our apps after April 30th, 2015 risk any of the following problems:

Also, as several of the most popular API calls and permissions will completely change their responses, you’ll need to refactor your app behavior in order to preserve your business model. Maybe you’ll need to ask for new permissions or even completely refactor some of your screens and actions. You’ll also need to explain to your current users that some features will no longer be available. Be prepared for everything.

Although you still have a lot of time to implement the necessary migrations, it’s better that you start working on them right now. You also need to take into consideration that maybe you’ll need to ask for additional permissions from your users. For every new permission, you’ll need to go through app review, which usually takes 3-7 business days. But don’t take this as a hard fact – in the upcoming two months, a large number of apps will apply for an app review, so the duration of this process could potentially increase to more than a week.

Facebook has already documented all the necessary changes and created a FAQ page especially targeting migration problems:

In conclusion, if you have regularly updated your applications, you’ll have no problems with the migration to API v2. Facebook has done a really good job with documenting all new functions, permissions and migration strategies. You can also join the Facebook Developers Community and ask any question you want to further simplify your migration process.

But don’t get too used to API v2. It’s already deprecated and will only be supported for two more years at most, and will probably be up only until April 30th, 2016.

With more than 80 percent market share, Android is the dominant mobile operating system today. It’s running on countless models of smartphones and tablets, as well as many other devices. Judging by this, one would think that programming for Android is simple and easy. Or is it?

A few years ago, Miley Cyrus was still singing country music, Justin Bieber wore his famous “Bieber” haircut, Malcolm still played in AC/DC and Android development was quite complex. Android developers had a lot of problems with developing even the simplest possible applications for Android OS.

Why? Well, my dear reader, problems were everywhere:

But that was like so 2013!

Everything changed last year, and changes were happening so fast that you could easily lose track of them and ask yourself, “When did this happen???” What’s even more important is the fact that the whole Android ecosystem underwent many improvements – we got new hardware (smartwatches), new software (Gradle, Android Studio), new OS (Android 5.0 Lollipop).

Everybody contributed – Google, device manufacturers, developers. Everybody had the same goal and asked themselves the same question: “OK, now we have stable OS, billions of apps with billions of users – how can we further simplify and improve Android? How can we make the development process better?” This is where open access and open source principles have shown their true potentials – everybody can make a change. An improvement. Something new.

It’s hard to summarize all the changes, but I’ve made a list of things which are (in my opinion) the most important:

Our favorite IDE for Android development finally became stable with the version 1.0. I won’t go into too much detail about why AS is great for the development process because we have already covered this topic in two of our blog posts (first and second). I’ll just say that the Eclipse ADT plugin is officially deprecated and I strongly advise you to migrate all your apps to Android Studio. Hail to the king!

Gradle is a project automation tool which has replaced Apache Ant as a primary build system for Android applications. It has gained huge popularity among Android developers because we can pretty much automate everything with it – from dividing our apps into different flavors, signing with correct configuration, incrementing our build numbers, defining external dependencies and much more.

Because of that, it has become a sort of an “administration” tool, with which we define and maintain our project settings. Gradle is also one of the main reasons for the increasing number of test automation libraries and automate build servers, which have brought the continuous integration (CI) development process to Android OS. But not everything is so rosy – Gradle is also heavily criticized for its speed of execution. It can be really slow on complex projects, but we hope that this problem will be fixed in the upcoming versions and releases.

Google said that Lollipop was the biggest improvement of Android OS since the beginning of mankind, and they were right. Every part of Android has undergone some modifications and improvements, but we are yet to see how users will react to the changes. We had a lot of problems with upgrading older devices to Lollipop, but we hope that this will be fixed in the upcoming versions.

A lot has been written about bright new Android UI, called Material Design. It’s one of the most important innovations on Android OS in the last few years, which has completely changed the look and feel of our applications. What I like the most about Material Design is the complete change of UX principles – everything is important. There is no such thing as tiny details which can be ignored. We have to respond to every user interaction, click, touch, etc. Because, as Google says, motion provides meaning. We have to be bold, embrace new vivid colors, use animations at every step, large fonts – simply said – we add life to our applications. Also, Material Design is completely adjusted to the Android ecosystem and it adapts to different screen sizes. That’s why our apps have a similar but not the same look on different platforms.

Everybody’s talking about design, UI components, animations, colors… But we are developers and we’re interested in what is under the hood. And, oh boy, the engine is pure beauty: a brand new runtime system, called ART. Just for the record, Android ART is not a new thing – it was introduced as a secondary runtime system on Kitkat. With the introduction of Lollipop, it became the primary system that has completely replaced Dalvik. ART is great because of several things, but I’ll mention only two of them:

We have started to develop apps for smartwatches, TVs and cars, but why stop there? If you are sitting in your room and having a cup of hot coffee, take a minute and look around yourself. You will probably see at least five things which will run Android OS in the next few years – the TV, laptop, tablet, camera, bicycle, kitchen appliances, thermostats, cars, etc. Android started as an experiment and it has proven that it can be run on every item which can hold a small microprocessor.

Smartphones are still core devices for Android OS. For a long time, we had problems with their overall quality. Older Android devices were much uglier and slower than older iPhones – iOS always felt more fluid. This was especially true for cheaper devices produced by a multitude of Chinese manufacturers.

Luckily, the quality and speed of Android smartphones have steadily increased, so today we have a plethora of new devices that are suitable for everyone’s budget and needs. It doesn’t matter if you want a mobile phone with great camera resolution, design, processor or battery – we have it all.

My personal favorite is Motorola Mobility (nowadays a subsidiary of the Chinese computer technology company Lenovo) with their great line of smartphones – Moto X, Moto G and Moto E, which indeed have a really good price/quality ratio. Also, a team at Google is working on a modular smartphone. Project Ara aims to completely shake the Android world and, if all goes well, it probably will.

As we have finally fixed most of our problems with IDEs and OS versions, we can shift our focus to other Android problems.

IMHO, the most important problem is the core problem of Android development – Java. Sorry, Java Harmony. Which is basically Java 7. Or Java 6. But is not Java. Don’t get me wrong – I strongly believe that Java is a good programming language, but I also think that it’s the right time to think outside of the box. We need to start looking for other programming languages that will replace Java as the primary language for Android development.

Just look at our most important competitor – Apple. They have introduced a completely new language called Swift which combines the best features of several other languages (like Python, Ruby or C#). We already need considerably more time than iOS developers to develop the same app, and now we’ll be even slower.

That’s why we need something new. We already a have few ideas about which language could replace Java. My eyes are set on Groovy. Its syntax is quite similar to Java (actually, it’s built upon Java) and we already have some working prototypes. Also, don’t forget that it is the primary language for Gradle – so why not use it in Android development? Or maybe Scala (which is quickly gaining new users) or Kotlin (Jake Wharton recently wrote a great overview of Kotlin for Android)?

I would also like to point out one more problem – database management API. If you commit blasphemy once again and take a look at our competitors – iOS (Core Data, to be more precise) – you’ll see that they have really nice methods and GUI for creating database objects, CRUD methods, database change listeners. But if you look at the default Android API – we still haven’t gotten far from writing SQL commands which greatly affects our development process.

Debugging SQL errors is not so easy – it’s time consuming, and we have no GUI for looking at our database data. Although there are some good ORM libraries (like GreenDAO, ActiveAndroid or SugarORM), they all have their own problems. I have never been completely satisfied with them – they have been either complex to use or something has been missing (like database change listeners). My mind is set on Realm for Android and DBFlow, which I’m hoping will solve all of my problems and will also have shorter execution times.

A lot has changed in the past few years for Android. It has evolved from a simple OS for smartphones and is now powering many other devices. Time will tell what will become of it. Who knows, maybe we’ll even program nuclear fusion reactors with it. Or Terminators. Terminators are more fun.

A year has passed since Google introduced Android Studio IDE at the Google I/0 2013 Conference. A month later, we wrote an article on how Eclipse would slowly, but ultimately lose its position and recommended switching to Android Studio. Over 25,000 people read this article. Were we right?

Today, in 2014, over 75% of the world’s smartphones use Android as their operating system. Soon, Android will evolve beyond mobile phones – it will be in smart watches, cars, kitchen devices, laptops. And thanks to the mercy of the heavenly Gods of Java, we finally have a state-of-the-art IDE for Android.

I’ve never been an Eclipse fan. I never liked it in the first place, but after years of use, I’ve grown to hate it to the point that I’d rather eat rusty nails than use Eclipse again.

I always thought of Eclipse as a ”student-project IDE”; I learned about it during my college years, did my lab work in it and used it to introduce myself to the world of Android development. But when things started to get more complicated – that’s when Eclipse started to frustrate me more and more.

You want to develop an application and use more than 3 projects in your workspace? OK, but you’ll have to clean your project and restart Eclipse every couple of minutes. You want to upgrade Ant? OK, but you’ll have to spend a few more hours to get your project back to life. You want to release your application? OK, but close all other active applications because Eclipse will crash every few seconds.

Android developers were desperate for a more stable IDE and were quite optimistic when Google announced Android Studio. Eclipse slowly started to lose its market share and in less than one year it became obsolete, a relic of some older, “darker” times.

It couldn’t rival Android Studio because it was designed differently, in different times. You can use Eclipse for a bunch of different programming languages and for a bunch of different platforms, but it couldn’t adapt completely to the world of Android development. On the other hand, Android Studio is designed specifically for Android development and its main goal is to speed up the Android development process and make it easier and simpler.

I’ve been using Android Studio for a few months now and have made a list of reasons why it’s, in my opinion, superior to Eclipse:

Android Studio introduced a new project automation tool – Gradle, which replaced Apache Ant. Have you ever tried to upgrade your Ant version while developing an Android application and cried in agony when your project exploded into millions of pieces? Upgrades are always frustrating and in 9/10 cases you have to modify Ant scripts or your project to bring it back to life.

Gradle also allows you to use different flavors of an application – you can define separately the development and production version. You don’t want to use Proguard and have different app icons in the dev and prod version? Just modify your build.gradle file.

Android Studio replaces references to resource files with their real values, so you can find out which color you are using or what is the height of the layout directly from the code editor.

I’ve always experienced a lot of problems while using graphical preview in Eclipse. In Android Studio you can build layouts and observe changes in real time. Heck, you can even track these changes on different screens!

Android Studio uses Lint by default, and you can modify your Gradle files to include Lint when releasing your APKs – if Lint finds some warnings, it will automatically abort your release process.

Why is this good? It forces you to use good Android development practices (like defining all of your dimensions in separate XML files, or avoiding hardcoded strings), it can point to unused resource files (which results in a smaller APK file in the end), mistakes or unused permissions in the manifest file etc. We want to speed up our development process, but we also want to produce quality code.

One of the most important steps in software development is testing – you want to avoid bugs and errors. In Android Studio you can define your unit tests in separate classes and launch them while building your applications. In case of an error, you know where your bugs are even before they happen in production.

Android Studio is fast – and by fast I mean really fast. Just for comparison – in Eclipse you need at least one or two minutes for building release versions of more complicated projects. In AS you can build the same project in less than 30 seconds.

In conclusion, in less than a year, Eclipse lost its position as the primary IDE for Android development and became extinct. By the mercy of the heavenly Gods of Java, we have also fought in this war, alongside other developers.

Now we are quite optimistic about how Android will evolve with AS in future years because Android development is once again fun and simple. Android Studio is the new king and we wish him a long and happy reign…

P.S. What are you waiting for? Go install Android Studio!

—


If you’ve enjoyed this article, read my latest piece about the future of Android development.

One month has passed since Google released Android Studio at the Google I/0 2013 Conference. After the initial fuss has settled, it’s time to make some remarks about this new IDE for Android development.

After Google announced its own IDE for Android development based on the IntelliJ platform (let’s face it, as the name suggests, it’s the most intelligent IDE for Java programmers), I was quite optimistic and happy about this exciting news. So I made some coffee, opened a fresh box of Domaćica cookies and downloaded the IDE from their official website.

I’ve never been a big fan of Eclipse for different reasons: a) it’s ugly, b) it’s buggy, c) it makes you start believing in heavenly creatures and divine wisdom of the Gods of Java & Android (it is a known fact that gods of programming exist, and you have to worship them in the form of yelling, cursing and drinking a lot of coffee). It is OK when you are developing smaller applications, but when your application has 10 projects and 10 external libraries, that’s when the fun begins – refresh project, clean project, restart Eclipse, and then all over again. I absolutely hate Graphical Layout when I’m developing UI elements, because it never works properly – at most I can only look at half of the screen after reopening it for two, three times… Also, we experienced a lot of problems with the newest version of Eclipse (it was crashing at least once a day).

The installation process for Android Studio went perfectly, and after starting the IDE, I was immediately amazed when I saw the brand new Studio – it was ugly and not sexy at all (so it was just like Eclipse). But guess what – you can change the default theme to a totally sexy, dark theme named Darcula (genius name) without hacks and workarounds. It uses really nice colors, and I absolutely love the default font (Lucida Grande), which looks fresh and cool.

Then it was time to import my first project – Streamoplayer, an application for streaming media files from the Internet or SD card developed in Eclipse. This is when problems started – Google said that Apache ant is old technology and they replaced it with Gradle in Android Studio. I won’t go into much detail about Gradle (here you can find more information on Gradle), just point out that first you have to create Gradle files in your project.

Of course, this is not as simple as it looks, because first you have to upgrade your Eclipse to the newest version (this could be the subject of a new blog post, because it is NOT as easy as it seems).

After I successfully upgraded my Eclipse and generated Gradle files, I said bye-bye to Eclipse and deleted it from my filesystem. Then it was time for the second miracle to happen – importing the project to Android Studio. Most of you have some experience with importing projects from different IDEs and know that it never goes smoothly. But, this is Android Studio, and it’s God’s favorite IDE for Android development – importing a project is as easy as just clicking the button Import. Puff, and it’s there.

After playing with AS for some time, I’ve created my list of 5 totally cool and sexy features:

But, I have to say that AS has a lot of bugs, which is not surprising, as it is still a work in progress. Some features don’t work sometimes (or don’t work at all), like replacing a R.string.something key with its actual value.

Users have also reported errors in workspace after creating a new project while they were not connected to the Internet. I really hope that this is a bug, because I find the idea of being connected to the Internet all the time while developing an app totally stupid and unnecessary.

AS is still not a polished product that I would recommend to all of the Android developer community, but I’m quite optimistic that most of the bugs will be fixed in the official and stable version (current version is 0.1.3, so it’s still an early access preview). The guys at Google really did a good job. I will keep my eye on AS and wait for the official version, and pray to Gods of Java & Android that the day when I won’t be needing Eclipse anymore is coming.

The future looks quite promising for AS, especially as Google is directly supporting the development efforts, and we all know how much Google cares about Android. In mine and God’s opinion (He is also an Android developer), Eclipse will be defeated by AS.

Resistance is futile.

—


If you’ve enjoyed this article, read my latest piece about the future of Android development.