I gave a talk entitled “Deep Dive Into Android State Restoration” at Droidcon France on Monday, this week. I have been asked if the talk was recorded. The short answer is: it was. Unfortunately the video is still being process by the guys behind Droidcon France. In the meantime, here are some resources you may find useful:
It’s no secret to anyone, APKs out there are getting bigger and bigger. While simple/single-task apps were 2MB at the time of the first versions of Android, it is now very common to download 10 to 20MB apps. The explosion of APK file size is a direct consequence of both users expectations and developers experience acquisition. Several reasons explain this dramatic file size increase:
- The multiplication of dpi categories ([l|m|tv|h|x|xx|xxx]dpi)
- The evolution of the Android platform, development tools and the libraries ecosystem
- The ever-increasing users’ expectations regarding high quality UIs
Publishing light-weight applications on the Play Store is a good practice every developer should focus on when designing an application. Why? First, because it is synonymous with a simple, maintainable and future-proof code base. Secondly, because developers would generally prefer staying below the Play Store current 50MB APK limit rather than dealing with download extensions files. Finally because we live in a world of constraints: limited bandwidth, limited disk space, etc. The smaller the APK, the faster the download, the faster the installation, the lesser the frustration and, most importantly, the better the ratings.
As some of you may know, I recently release my first publicly available Android Wear application: Capitaine Train Android Wear1. As part of the design and development process I had to create some mockups and wireframes. All of these prototypes were made thanks to Photoshop CS6 and based on a 280x280 document. This square document represents the actual screen resolution of one of the currently available Android Wear watches: the LGE G Watch.
Working on full-frame screenshots is usually enough in the design and development phases of a mobile app. But when it comes to marketing, communication and promotion, device-frame screenshots should be favored over full-frame ones because they give life to your product. Indeed, device-frame screenshots have the advantage of bringing your application to the real world by associating it with the objects/devices it will be running on.
Because I recently had to give some Android Wear-related presentations, I wanted to have a nice and simple way to integrate my screenshots into actual device frames. I had a look on the Internet but was quite disappointed about the resources currently available2. As a consequence, I made my own device frame and would like to share it with you so that you can use it in your presentations or simply when promoting your Android Wear app.
In the past week there have been a tremendous number of discussions, tweets, posts, articles, etc. about some new and modern programming languages. There is no doubt that these sudden swirls have been motivated by Apple unveiling a brand new language called Swift at WWDC 2014. Being on vacation for the past two weeks, I have read quite a lot about the Swift programming language, its syntax, its features, its Objective-C interoperability, etc. But I have also seen some people claiming Android, from a developer point of view, is out of date compared to iOS? Why? Because it is based on Java.
To be honest, I agree with them. It has been a long time I have been claiming Google should ditch Java for another language. The thing is I think Google has been working on a replacement programming language just as long as Apple did - in secret - on Swift (i.e. 2010). So? What is this modern programming language? Some people think Go would be a great fit, I personally think Dart is more appropriate. I read and learned a lot about Dart during my vacation. From my point of view, for many reasons Dart is better for Android than Go: it is more mature, it is VM-based (just like Java), it better fits the Google ecosystem and it has an extremely easy learning curve while still remaining a simple language. It’s clearly time for Google to make Dart the future of Android and, in a global fashion, the future of the company itself.
Note: I generally blog about subjects I don’t deal with in my day to day life at work. However, the article below mentions some work I have done at Capitaine Train. As a consequence, I think a disclaimer is needed here: I work for Capitaine Train, but the opinions expressed on my blog or anywhere else (Twitter, Google+, etc.), are my own, and have nothing to do with my employer.
In the past few months, I have been working on developing an Android application from the ground up. This app named after the name of the company, Capitaine Train, can be downloaded on the Google Play Store. Capitaine Train - which can literally be translated as “Captain Train” in English - is a 3-year-old startup born from a simple truth: getting train tickets in Europe was a pain in the ass. We, at Capitaine Train, aim to revolutionize the way people travel all around Europe by simplifying the overall train experience. The release of the Android application clearly represented an important step forward in this direction.
Trying to revolutionize the train experience in Europe is not easy. It requires us to achieve a tremendous amount of work: getting to know the various carriers, learning about the document/reservation requirements for each of them, integrating their price/time tables, binding our servers to their systems, etc. From a user point of view all of this is the hidden, but vital, part of the iceberg. Indeed, a travel need or desire starts from a simple search request: From where? To where? When? Who? Although these questions are simple, the search step is extremely important in the booking process. This is where the trip actually begins after all! We designed the Android app keeping this essential idea in mind by simplifying every bit of the process. In this article, I would like to tell you the story behind the implementation of the search experience in the Android app and how we used animations to enrich the user experience.
Recently, I have been asked several times why I wasn’t blogging anymore. The answer to this query is quite simple: I have been both busy and lazy^^. Busy mainly because of the enormous amount of time I have spent working on, polishing and tweaking the Capitaine Train Android application. Lazy because … hmmmm well, I’m sure you’ll agree with me, it’s relaxing to be lazy from time to time!
Me not posting on my personal blog doesn’t mean I’m not active anymore. Even though I’m not publishing new articles here, I usually keep on sharing some of my thoughts on UI, UX, mobile development – or more generally on all of the topics I love discussing about – on some other web media. In this article, I would like to discuss about these web media I appreciate and use regularly.
A year ago I shared some graphic assets to help developers and designers create applications that are consistent with other map-based Android UIs. At that time, Google Maps Android API v2 didn’t exist and developers had to use the Google Maps External Library which was - I won’t mince words - so poorly implemented you had to create everything on your own (markers, info windows, etc.)…
The release of Google Maps Android API v2 has been a huge step forward regarding map rendering capabilities on Android. The new framework has suffered and still suffers from sometimes unpleasant drawbacks1. From a designer point of view, it has one main advantage over the previous framework: it is bundled with a bunch of default resources. In other words, Google Maps Android API v2 helps developers with no particular design-skills to create nice-looking maps and improve design consistency through applications.
In the past 6 months, my Android development environment has changed quite a lot. If you follow me on Google+ and/or Twitter, you may have noticed these changes reading some of my latest tips. I love talking about UI and performance but I also seriously consider tools are crucial entities in the process of developing nice and polished Android apps. In this post, I share about my experience and the tools I use everyday when coding:
- A blazingly fast virtual device: Genymotion
- A powerful IDE: Android Studio
- An evolved build system: Gradle
Back in November 2012, I wrote a blog post entitled “ActionBar on the Move”. This article was mainly dealing with a technique to nicely and uniquely animate your
ActionBar. Although I mentioned some of the effect’s possible applications, I never had time to effectively add an
ActionBar animation to one of my own apps nor saw an application on the Play Store taking advantage of it.
While being at Google I/O last week, I finally found an application using the
ActionBar animation technique. Let’s be honest, it literally blew my mind the first time I saw it. I felt in love with the nice, subtle and yet extremely useful animated effect probably more than the entire app itself! I am pretty sure you know the application I am talking about as it has been presented during the Google I/O keynote. You have also probably recently received an update of it: Play Music!
In October 2012, I released a library called Polaris. At that time, the library received quite a lot of success because it was really filling the mammoth blanks of the Google Maps external library (aka Google Maps Android API v1): effortless map annotation, gesture support, map callout support, built-in “user tracking” mode, etc. If you have never heard of Polaris feel free to checkout one of the links below: