These are all from within Italy, mostly in Veneto but some also from other regions, and as you will see they cover pretty much every season I was ably to hike and fly.
Enjoy!
In this time it’s even more important that people like me, who worked full-time remotely for a long time, give some help at least providing some sort of normality in this challenging period.
So together with the other fine folks on the Android Developers Italia community, we decided to start a series of 100% remote meetups, each one with a guest speaker, an open discussion at the end and live audience questions.
I gave my talk about Kotlin as a scripting language last week and you can watch the talk and following discussion here:
This initiative proved a great success already and we have dozens of more talks planned already for the next weeks!
]]>There are however some incredibly useful features that most developers don’t know about.
I created a video lesson on Caster.io where you will learn how to use custom Data Views to obtain the most out of Android Studio debugger, by creating custom representation for given classes in the debugger view and immediately inspect only the most relevant information of the current state of your app while debugging.
It’s a free lesson, you can watch it here:
Make Android Studio debugger more powerful with custom Data Views | Caster.IO
]]>I never managed to see it in real life, until a few weeks ago, when I got to film it in a winter, snowy morning while it was running through a valley in the Alps. Here it is a video I shot with my drone and a few pictures from the day.
A Kotlin script is a simple Kotlin snippet, without the need of the main
function that you would need in a typical program. That function is actually implicit, and all the commands in the file are executed as if they were the main
body.
The script file can be simply run invoking the kotlin compiler with the -script
parameter.
The executed script can accept input arguments:
and also make use of the Java and Kotlin stlib in order to access more powerful libraries:
Of course using Kotlin also allows us to access other concepts of the language, like functions, recursion, classes or extensions, which can make our scripts even more readable and maintainable:
While all this is already a good start, we can greatly improve our scripting experience by using a third party open-source solution: Kscript.
This tool adds a lot of niceties that make scripting with kotlin even more fast and powerful.
First of all kscript adds more ways of invoking a script. It is possible to run it by specifying the script file
$ kscript helloScript.kts
or by specifying a URL containing the code of the script
$ kscript https://gist.githubusercontent.com/danybony/.../kscriptUrl.kts
inlined
$ kscript ‘println(“Hello there”)’
or by piping a Kotlin snippet into kscript and instruct it to read from stdin
$ echo '
println("Hello Kotlin.")
' | kscript -
The URL input mode is particularly powerful in my opinion, as it allows to easily create a centralised repository of scripts that can be executed remotely on several machines and maintained in a single place.
kscript can act as interpreter for a script by just specifying it in the shebang line the Kotlin script:
Finally, kscript can also be used to deploy script as standalone binaries with the --package
parameter:
$ kscript --package helloScript.kts
[kscript] Packaging script 'helloScript' into standalone executable...
$ ./helloScript
Hello world!
Another great addition in kscript is the caching mechanism. Kotlin scripts are still compiled using kotlinc
under the hood, but before doing that, kscript checks if the script changed from the last compilation (by hashing the content of the script). In that case a cached version of the script is immediately executed, without wasting time recompiling it. This has, as it’s easy to imagine, a very positive impact on execution times.
Third party libraries can be used in our scripts, including them as dependencies using directives or annotations, and specified with gradle-style dependencies locators, with group id, artifact id and version. This allows us to access more powerful tools like, for example, coroutines:
Other local files (or different kotlin snippets from URL) can be also included as dependencies into the current script by using the //INCLUDE
directive:
kscript makes it super easy to edit kotlin scripts too.
By using the --idea
parameter, it creates a temporary, minimal project and automatically opens it with IntelliJ IDEA. This project only contains the script file and a generated gradle.build
, and after a Gradle sync it’s possible to immediately access all the powerful IDEA tools, including auto completion and sources from the included script dependencies.
There are several very well known alternatives for creating scripts, but Kotlin is definitely the best I’ve tried. With the addition of kscript, its caching and third party dependencies, it’s very easy to quickly create powerful scripts that are highly maintainable too thanks to the use of the Kotlin language.
In November 2019 I gave a talk about how to start with scripting in Kotlin at Devfest St Petersburg, Russia. Here you can find the slides for that presentation:
]]>In this talk I gave at Devfest Veneto 2019, I showed the main concept behind Google Cast, seeing how it can be used to to create a more central, prominent space for the most important content of your service.
My hometown Caltrano were hit too, even if in a minor measure, with some areas of the town mountain wood flattened by the storm. To remember this event I decided to capture this through the different point of view of my drone. The vantage point this tool provided, allowed me to give some context to the different places where the forest had been most affected by the fury of the wind.
The resulting pictures were exposed in an exhibition in Caltrano, Italy, the 13th of October 2019.
To know more about which features we added to it and how flexible it is, you can find more details in this blog post.
I gave a talk at Droidcon Turin 2019, where I explained some of the reasoning behind most of the choices we did while creating this new library, what we considered in order to make it maintainable and extensible, and how to be good citizens by making it open-source and allowing others to contribute to the project.
These are the slides for the presentation I gave:
And this is the recording:
Flutter is created with the app UI as main priority, allowing developers to create beautiful native app with pixel-perfect experiences on both iOS and Android. Flutter apps run smoothly with beautiful animations and the development cycle is incredibly fast, thank to the hot reload feature which allows to see almost instantaneously any changes to the UI while developing.
While this framework is relatively new, there are already quite a lot of apps built using Flutter and the number is constantly growing.
On the 21st of January 2019, I gave an introduction talk about Flutter on a local meetup named Programmers in Padua.
This is a meetup whose members are involved with software development, both professionally, for passion or still studying it.
While the audience is not only mobile-centric, I thought that Flutter could be an interesting topic for this kind of event, especially considering the latest announcements about bringing Flutter to the web and desktop.
These are the slides for the presentation I gave:
And this is the recording (in Italian):
The idea behind the project is simple: attendees at the wedding would press a button to take a picture. That photo is then shown for review and shared with the other attendees.
The core of our device is a Raspberry Pi 3 running Android Things. That was connected to a big red button which made it immediately clear what the user needed to interact with, to start the photo capture. The camera module we used is a Raspberry Pi Camera module v2, which has a true 8 Mpx sensor and produces pretty good pictures, even with low light.
The Raspberry PI is connected to a monitor through HDMI and at first we tried to implement a live preview from the camera. When we worked on it, however, Android Things wasn’t able to render a fluid video stream from the camera, so we went for a workaround: we transformed the monitor into a magic mirror. By using a two-way film, the monitor reflects the people in front if it when the background is black, like a traditional mirror. On the other hand, displaying bright text or images, these are visible through the mirror. This workaround allowed attendees to place themselves on the frame after pressing the button, while a countdown was displayed.
Once the picture is taken, we store it locally as a jpeg file, and when a network connection is available we upload it to a shared Photos album, using the Google Photos API. This automatically notifies all the attendees participating to the album that a new picture has been taken. Given the unreliability of the network, we used Android Jetpack’s WorkManager to schedule a task to upload the stored picture to Photos immediately when a network connection is available.
Google Photos API requires the user to be logged in with the same Google account that created the album where the pictures are being uploaded. Given that our device doesn’t have any keyboard or touchscreen, we created a mobile companion app running on an Android phone. Through this app we could easily login to the right Google account, create a new Photos album and then send the needed information (auth token, configuration, etc) to the device. For the connection between the smartphone and Android Thing, we used Google Nearby, which allowed the two devices to discover each other and share data without any previous configuration.
This weekend Roberto and I spoke at DevFest Gorky in Nizhny Novgorod, Russia, presenting the project with two talks. It was an amazing conference, brilliantly organized and with with a very active audience. Kudos to the organisers for such a great event!
In the first talk we covered most of the hardware aspects and included an introduction to Android Things. You can find the slides here:
In the second talk we focused more on the software aspects of the project and the new Google Photos API:
While we created this project for a specific event, it is still active and we are planning to add more features on it in the future. It is also open source, so if you want to know more just have a look at the official repository.
]]>