(As usually…) It has been a while since my last blog post 🙂
This time I’m coming back just to tell you briefly about Google I/O 2016!
Last time it was back in 2013 when I went with my friend Massimo and since then a lot of things have changed. The Android platform got a lot more mature and my impression is that Google started to focus more on simplifying the developer life while still gaining a lot of new data.
I’m not gonna talk about VR, Artificial Intelligence and Machine Learning. These are really cool technologies but my developer heart still belongs to an Android made of custom UIs, Content Providers, messy fragments, multi-threading, memory constraints,… and… why not… Android Studio!
It’s kind of funny because back in 2013 when Tor Norbye and Xavier Ducrohet announced Android Studio starting to ditch support for Eclipse, I was a bit upset. After few months, I started to appreciate IntelliJ and all the efforts that the Android Developer Tools Team made in order to have a first class Android IDE integration/experience.
…but this is the past!!! Without forgetting about being dwarfs standing on the giants shoulders, let’s focus on the present and what’s ahead of us! 🙂
This Google I/O 2016 came with a lot of news:
- Android N will support native Multi Window with Drag&Drop capabilities.
- ConstraintLayout: not a RelativeLayout, not a FrameLayout, not a LinearLayout, not a PercentageBlaBlaLayout,… but a completely new ViewGroup that comes with a full integration in a new layout editor for Android Studio. The power of this new tools is based on the promises of flattening drastically the View hierarchy creating constrains between Views and parents! 🙂
- Java8 support + Jack Compiler
- An APK analyzer to inspect generated APKs and help you try to remove un-necessary and/or un-optimized resources
- Instant Apps is a new feature that will allow you to modularize more your application allowing the user to download just a single use case of your app, without having to install a full APK. Even if it might look a bit strange, this tool could be really handy when it comes to introduce your service to new users, engaging them little by little.
- Android Wear 2.0: even if it comes as a preview, it will have a new enhanced user interaction and more immersive experiences.
- Watch Faces will support more than just time and battery info. There will be a chance to support more complicated(complications) data that will provide useful info to the user.
- Notification will come with a new interaction style and paradigm.
- Firebase: this is kind of hard to describe. The most simplest description that comes in my mind is “A magic box that contains a lot of tools to help you build better apps“. All these kind of little things those are taking a lot of time when developing new features in your apps will become definitely a lot easier. A/B testing, analytics, syncing, login, GCM,… have been bundled and connected(not all of them) togheter into Firebase, giving you a simple way to check and maintain them.
…there is definitely a lot more and you can check it out on the Google I/O 2016 Youtube channel!
I hope you’re gonna enjoy some of the pics I took over there 🙂
..if you live in UK, have a long weekend! 🙂
Being at the last step of our Android Wear journey suggests us to make some assumptions and considerations on how to take advantage of this new platform in real scenarios. Beside this, we are going to have a brief look at some of the missing elements that we did not touch before, focusing our attention on answering the questions those might have risen in the mind of the readers while going through the entire path.
Since the beginning of our journey, we have tried to create a wearable experience starting from our existing handheld app. A first working solution has been achieved just taking advantage of the WearableExtender that has allowed us to easily extend the status bar notifications, providing detailed info and extended functionalities to the wearable device. Even if this approach can work for the majority of the applications and it is really straightforward to achieve, it has some drawbacks in terms of achievable features and availability of content on the smartwatch. In fact, if the smartphone and the wearable device are not coupled, the latter one cannot offer any more access to the previously shown content. Keeping in mind that the wearable device is not a substitute of the handheld one but more like an extension that should try to simplify the user life, we have then exposed a limited number of functionalities into a custom wearable app. In order to achieve this result both applications currently share a common module but are decoupled in terms of single application modules. In this way it is possible to recycle and share code elements like the ContentProvider, the models and common utilities but at the same time keep distinct the different platform based implementations. In ‘Pimp my Wear’, this solution has led us to a wearable application that can be used by the user even if the two devices are temporarily disconnected but at the same time to a situation where the content gets out-synced. In this chapter we are going to have a look at how the Wearable Api can help us exchanging and syncing data between the two different devices.
In “Colonizing Wearables”, after a first attempt of running the existing handheld version of the Books application on a smartwatch, we ended up creating a simple Android Wear module that displays the number of available book entries. This has been done not only to discover more about Android Wear, but because a handheld app should not be just ported to a wearable device. During our journey, we have introduced few of the new UI components offered by the wear support library. Among them, WatchViewStub has allowed us to handle different screen shapes, figuring out at runtime the type of display. We also had a chance to understand the reason why and how the wearable module has to be included into the handheld build. Therefore, the goal of this part is to evolve the previous module into something that can be easily used by user and that tries to follow as much as possible the android wear design patterns.
In “Landing on Wearables” we have approached wearables devices extending our existing app’s notifications and explaining briefly how to bind them to our development machine for debugging purposes. Now it is time to study more in deep what we can achieve directly on a device running Android Wear, understanding the constraints and the possibilities that the platform introduces. We will continue to keep as reference the Books application previously developed and we will try to create an Android Wear module.
In “Introduction to Wearables” we had a look at some of the concepts those are the foundations of Android Wear. In this part we are going to skip completely any considerations on that and we’ll have a look at how things work underneath. In particular, we’ll have a look at how to extend existing application’s notifications and how to debug on wearables(this second part will be used for the following tutorials). In order to achieve this, we’ll start with a sample application that runs just on a handheld device and we’ll try step by step to extend it, trying to create a beautiful user experience even on a device running Android Wear. Read the rest of this entry
Wearable devices are definitely one of the most exciting and coolest technologies of 2014 along with drones and smart cars. Hardware producers, software companies and even start-ups are pushing the boundaries beyond what is just being on a handheld device, struggling to open new challenges and attract new customers. Something similar has been already seen when smartphones were just at the beginning of their appearance, but this time the purposes and targets of this technology are a little bit different. It is not just a matter of keeping the user connected with the World outside but it’s more about offering him new services, getting more from/into his life. Sensors can collect data about user activities (heart rate, pedometer, burn calories, sleep hours…) allowing to know more from the user’s context and his behaviors. Embedding them on wearable devices(smartwatches, rings, betls,…) can grant almost a 24 hours coverage, attracting the user to use something that he is already used to wear but with more functionalities and fancier. Read the rest of this entry