For people who are new to programming to those who want to sharpen their coding skills, Hacker Rank has been running the 30 days of code challenge.
Every day a new challenge is posted ranging from introductory topics to mid-level challenges. There is also a new video tutorial every day related to the topic of the challenge.
It is a great way to practice problem solving skills and it accepts solutions on several programming languages, such as Java, C, C++, Clojure, D, Fortran, Go, Perl, Swift, Objective-C, Python, among others (you can even code on the Brainfuck language!).
This week Sundar Pichai, Google CEO, announced in a tweet that Google I/O 2016 has been scheduled for May 18th through the 20th. It will take place on Mountain View’s Shoreline Ampitheatre, back where the conference first stated.
Android N, updates to Project Tango, Google Cars, Android Wear, Chrome OS, Project Ara and a possible second-generation model of Google Glass are expected!
Google announced today Android 5.1, with an API adding support for multiple SIM cards, enhancing enterprise features to better support the launch of Android for Work, deprecating HTTP classes, adding support for telecommunication service providers and more!
One of the most anticipated events for Android developers, Google I/O, will occur on May 28-29 and will take place at the Moscone Center West in San Francisco.
Registration for tickets will open on March 17th at 9:00 a.m. PDT and will run for two days. Just like last year, Google will pick the people who will “receive the opportunity to purchase one ticket” at random.
It will also be possible to watch the keynote and select sessions in real-time, from a laptop or mobile device.
More information can be found on the official website: Google I/O 2015
Today at work a friend gave me a very good tip to update properties of all modules of my project from the main project.
My project has 6 modules and a main (root) project. What I used to do when releasing a new version of an app, or updating a property such as build tools, was to go to each module and manually update these properties on their build.gradle file:
Today I will talk about a very important topic in Android mobile apps development: managing the lifecycle of an activity.
When someone navigates through an app the Android system calls a series of lifecycle methods on activities in which developers can set up the user interface and other components and actions. One example is when an user performs an action that starts another activity. When that happens the system calls another set of lifecycle methods on the activity as it moves into the background (where the activity is no longer visible).
The following picture (from Android developer training website, a great place to learn things about Android) shows a simplified illustration of the Activity lifecycle.
When the user first opens an activity the onCreate() callback is called. This method should implement basic application startup logic that should happen only once for the entire life of the activity, like the definition of the user interface.
Once onCreate() finishes execution, the system calls the onStart() and onResume() methods in quick succession. The activity never reside in the Created or Started states. The onStart() method is a good place to verify that required system features are enabled. The onResume() method should perform any other initializations that must occur each time the activity enters the Resumed state (such as initialize components only used while the activity has user focus).
The system calls the onPause() method when the activity is still partially visible and most often is an indication that the user is leaving the activity and it will soon enter the Stopped state. The onPause() callback should be used to stop animations or other ongoing actions that could consume CPU, commit the necessary unsaved changes and release system resources.
The onStop() method is called when the activity is no longer visible and should be used to release almost all resources that aren’t needed while the user is not using it.
The last last callback, onDestroy() is called by the system as the final signal that the activity instance is being completely removed from the system memory. If the app decides to implement this method it can be used to kill background threads created during onCreate() or other long-running resources that could potentially leak memory.
This explanation was a summary of the main points related to the activity lifecycle. There is a lot more involved, especially if you decide to use fragments in your activities. For more information, check the Android developers training website.