Android, Android, Android… It’s everywhere – smartphones, watches, tablets, TVs… Android is getting sexier and more stable with each release and, with a ton of learning material available, this is a great time to start learning how to develop for this platform.

The primary target audience of this article are fresh computer science graduates who are thinking about becoming professional Android developers. Basically, I wanted to write an article that I would have loved to have read 2.5 years ago, when I scored my first paid dev job.

In it, I present a roundup of facts and resources that will give you a clear picture of your future work scope. Start contributing quickly, experiment and enjoy yourself in the process.

Note: consider this post a cheat sheet that you can come back to anytime.

Here at Infinum, we prefer working in Android Studio. A couple of words from my colleague Željko about AS can be found here.

Although a career in development probably sounds awesome, coping with deadlines and client expectations is something you have to live with on a daily basis. Check out this great article by our JavaScript team leader (or dictator, as he likes to be called), in which he touches upon different challenges that await every developer.

I was sitting with our design team for a year (we had a smaller office back then and I was moved there with another colleague to handle a two-man project). During that period I started paying attention to the problems/challenges that designers have to cope with.

This helped me broaden my perspective and start seeing new stuff, like “where on earth is that pixel going”, “Oh no, you didn’t use that color/font”, etc.

Paying attention to design details (UI/UX) will make you a better developer overall because you’ll get a better understanding of the product development process as a whole.

You become more creative, and creativity is fun and essential for building great apps.

There are problems in software development that tend to repeat themselves. This is why we (developers) create libraries to help us reuse code, simplify the usage and speed up the development process. Here are some of our favorite libraries that we use in almost all of our projects.

At the end of this article, you can find some influential Android players too. I suggest you follow them on Twitter.

Check this out for some implementation tricks: DevBytes.

Here are some of the Android development community hot shots you should keep your eye on. I linked their Twitter accounts because that’s the easiest way to follow their work:

As for the newsletter – subscribe to AndroidWeekly to stay up to date with the hottest news in the development community.

Let’s talk about “Increasing your chances of becoming an Android dev”.

There is a lot of stuff to read, study and try out. Try to find the best theory-practice pair cycle in order to learn quickly and try out new stuff. The right balance is achieved with time and trial and error.

Tasks let you cross out stuff once you’re done and give you a great sense of accomplishment. Plus, creating tasks will improve your analytical skills over time and you will get much better at structuring work and scheduling time. Prioritize work. You’ll improve with time.

If you accomplish something great one day, acknowledge that as well. Don’t write down only failures. The retrospective helps you consume the knowledge that you have acquired and reflect on it in a proper and constructive way.

Retrospective is a great tool, try it out!

Learning to be a developer is a process that doesn’t involve only programming. It’s about finding the right information, optimizing the information flow, applying that info, writing code, trying out different approaches, making mistakes and learning from them. Thus, gaining experience all the time and iterating in the learning process.

Follow the instructions above and increase your chances of staying ”in the flow”.

Good luck!

Follow me on Twitter: @vitongs

As a part of Android 4.4 KitKat, Google decided to introduce a new way of executing apps on top of the Android operating system. Let’s take a closer look at what this new runtime, called ART, brings to the table.

ART is Google’s 2-year-long ongoing secret project, which aims to boost the performance of our Android devices. It’s based on the premise that modern devices are pretty powerful in terms of CPU speed and memory capacity, especially in comparison with the first generation of Android devices.

ART is a new Android runtime being introduced experimentally in the 4.4 release KitKat. This is a preview of work in progress in KitKat. It is available for the purpose of obtaining early developer and partner feedback. – Android developers

In other words, ART is still an ongoing project, considered too unstable to be introduced as a standard runtime. Luckily, there is no special hacking involved to get it running.

You can choose to use it by going to “Settings> Developer Options> Select Runtime” and choosing ART.

Hmmm, but why would I want to make the switch?

Android apps are deployed in Dalvik bytecode, which is portable, unlike native code. In order to be able to run the app on a device, the code has to be compiled to machine code.

Dalvik is based on JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.

ART, on the other hand, compiles the intermediate language, Dalvik bytecode, into a system-dependent binary. The whole code of the app will be pre-compiled during install (once), thus removing the lag that we see when we open an app on our device. With no need for JIT compilation, the code should execute much faster.

Except for the potential speed increase, the use of ART can provide an important secondary benefit. As ART runs app machine code directly (native execution), it doesn’t hit the CPU as hard as just-in-time code compiling on Dalvik. Less CPU usage results in less battery drain, which is a big plus for portable devices in general.

Let’s take a look at the downsides of AOT compilation.

First of all, the generated machine code requires more space than the existing bytecode. Moreover, the code is pre-compiled at install time, so the installation process takes a bit longer. Furthermore, it also corresponds to a larger memory footprint at execution time. This means that fewer apps run concurrently.

When first Android devices hit the market (like HTC Magic shown in the picture), memory and storage capacity were significantly smaller and presented a bottleneck for performance. This is the reason why a JIT approach was the preferred option at that time. Today, memory is much cheaper and thus more abundant, even on low-end devices, so ART is a logical step forward.

The guys at Android Police made some nice benchmarks, and if you are interested in the exact numbers, check out the following link for more info.

Let’s take a quick overview of the results of their benchmarks:

Pretty neat, don’t you agree? There is one more hidden, but very important benefit of ART. When you ask iPhone users how they feel about the look and feel of Android smartphones, they often complain that Android feels laggy, despite the fact that hardware on both phones is top notch. Perceived lag/delay is the result of JIT compilation and it more or less disappears after switching to ART.

At the moment, there are reports that some apps are currently not working when you switch to ART, such as Whatsapp and Titanium Backup. I personally witnessed Whatsapp crashing each time on app startup, so I switched back to Dalvik again.

Being an Android developer, each time I make some changes that I want to test, I have to install a new app instance on the device. As stated before, ART uses AOT compilation, which prolongs the install times of applications because the Dalvik bytecode gets compiled to machine code. Therefore, each time I deploy a new version of the app on my device, I have to wait for this additional time to pass so that the app optimizes for the ART runtime. This causes a significant delay in the deployment process.

Install times on my Nexus 4, for one of our larger projects, jumped from ~17 s to ~25 s.

Personally, I saw an improvement in the speed and smoothness of scrolling in apps. ART makes the UI feel more responsive. At this time, Android ART is not fully optimized. I expect even better results in the future, after Google acquires more feedback and makes additional optimizations. As I see it, end users will definitely benefit from the switch, once ART matures and gets more stable. However, developers, who frequently deploy apps, will feel more intensively the negative impact of prolonged install times.

Android 5.0 with ART fully functional? I surely hope so!

The new Android 4.3 brought us a hidden section in Settings which enables revoking of permissions used by installed apps. Let’s see what effect this will have on users, developers and companies when it comes to privacy, improved usability, profit and software design.

First of all, let’s see what the competition already has in comparison to App Ops. Afterwards, we will have a look at the current implementation of App Ops. Finally, we’ll cover benefits and drawbacks of this new feature and the extent of its impact on developers, users and Android as a whole.

Unlike Android, iOS doesn’t ask the user to accept app permissions when installing the app. On iOS, the user is prompted to allow the usage of private data only once the data is requested. In my opinion, this is a fine approach, because the user can see the specific moment when the permission is requested and, therefore, transparency is guaranteed.

Contrary to iOS, Android asks for permissions once, when the app is being installed, and doesn’t provide the user with the possibility to disable some permissions/features of the app later on.

This is all changed with a hidden feature released in version 4.3 (Jelly Bean), which allows users to revoke permissions after installing a particular app. If you are lucky enough to have an Android 4.3 device in your pocket, you can try App Ops Starter, a simple app which unlocks Google’s hidden App Ops interface for managing permissions of installed applications.

The guys from Android Police who discovered this feature also found a textual resource in the package manager, indicating that the user will also have the possibility to revoke permissions at the time of installation as well.

Please beware: when you start revoking app permissions, most, if not all, of your apps will crash and won’t be usable. That’s expected, because current versions of installed apps are not yet aware that their permissions can be forcefully revoked after installation.

iOS permissions are grouped in a pretty simple manner: Location Services, Contacts, Calendars, Reminders, Photos, Bluetooth Sharing, Microphone, Twitter, Facebook and Push Notifications. The user can revoke them at any time from the Notification Center (Push Notifications) and Privacy (all other permissions).

Android has quite a bit more of permissions and it will be interesting to see how App Ops will group them in order to logically disable parts of the app. Will it follow the permission groups that already exist or will it use a more fine grained approach with smaller groups of interest?

There are four handy tabs: Location, Personal (Contacts, Accounts), Messaging and Device (hardware features, such as camera). Each tab displays when an app used OS features or collected data.

NOTE: Some permissions only appear in the permission list once they are first used.

So, it seems that selective permission handling on Android could be a great thing. The openness of the platform strikes once again and gives users the possibility to even more freely choose the interaction and behavior of apps installed on their smartphone or tablet. Let’s check some benefits and drawbacks of the current implementation of App Ops.

As stated before, in the long term, App Ops could provide a nice boost in terms of quality of code, as it will force a more modular approach in app development, which will reflect in a plug-in architecture dev approach/design.

Android will benefit in the way that users will see that Google cares about their privacy and freedom of choice by forcing software companies to adapt. Users just have to sit back, relax, and wait for the change.

The biggest drawback will once again be slower adoption of the feature due to Android fragmentation. Some users won’t be able to update to the latest version of the OS and some will be left out intentionally by some Android device vendors.

Overall, the reputation of the platform should see a positive boost and push the competition further away.

Stay tuned for updates!