Android Development
Content
Android Development
Individual study on mobile development for Android
Author: Robert Ontiu
University College Nordjylland
Android Development
Android Development
Individual study on mobile development for Android
Introduction
This report intends to present and evidentiate the process of learning the basic concepts on developing Android applications as well as the problems encountered on the way. The purpose of the process is not to create a final, working product but, instead, to try different approaches on the subject and experiment with the amazing functionalities the system provides. To start with, I personally believe that Android, as a software development environment has grown exponentially for the past years and it brings a new market in the area, offering amazing opportunities for software developers to easily create and deploy their products. Starting to learn Android development has been a good choice for me for two main reasons: It brings a new, ongrowing market for software developers eager to affirm and express their ideas and knowledge The fact that Android itself is an open-source product perfectly suits my beliefs that a product design by “people” offers a better experience than any other product designed by corporations (e.g. products designed to be marketed only)
Description
During the time spent on learning the topic I have focused my attention on understanding the concepts of Android, both abstract and concrete, as well as learning the core libraries the system provides while implementing some of them in experimental applications. Some of the information I’ve researched has not been new to me while, on the other hand, I’ve encountered some interesting concept s which were a bit trickier to understand.
1
Android Development
Learning outcome
To start with, the Android is built on top of a Java Runtime Library (JRE). While I was very familiar to Java, the harder aspects of learning became the understanding of Android libraries as well as the concepts of structuring the application.
Abstract concepts
In contrast to other development environments I have studied before, Android implements rigorous standards for both designing and coding your application. While on the design phase the system provides tons of components that are just to be added and bind to the application, the development phase has to follow structure standards and other abstract concepts in order to work properly. The most similar approach I’ve encountered before is the .NET development environment which I think, implements even more rigorous standards. One of the important aspects that caught my attention is that the system itself (Android) is user-centric (more details are to be found here: http://developer.android.com/design/get-started/principles.html). Some of the principles I remarked from this list are:
Use “real objects” (visual entities that can be manipulated by the user) Get to know the user (use previous actions to simplify tasks) Take advantage of the visual standards to make the UI look familiar
The architecture of the system is also something new to me and I personally appreciate and enjoy the way the system is implemented. In Android, each application represents a user of the system which is assigned permissions (through contracts) by the superuser (which is ultimately the person operating the system). Therefore, when you are designing an application, you have to think about the permissions you would like to acquire and create a contract to be sent to the end user.
Learning outcome 2
Android Development
Fundamental concepts
In opposition to other architectures, applications running on Android have more than a single access point (depending on the nature of the project). I can think of these “access points” as separate entities running individually and providing, each, a different functionality. They can be ran both, from within the application itself or, with proper permissions, from any other application within the system. The system provides the developer with only four types of functional entities (or access points):
Activities which are applications ran in fullscreen mode, providing an user interface and becoming inactive when they are closed or lose focus (minimized) Services similar to Processes in Windows or Demons in Linux do not provide an user interface and run in the background Content providers similar to Streams from .NET – are used to read and write content to internal storage or databases Broadcast receivers are entities that listen to system events and take actions accordingly
At a first glance a was a bit let down by the feeling that such a flexible system would impose such rigorous standards, however, after a peak into development a believe that they perfectly suits the principles and desired functionalities of the system and even more, they also feel as flexible as the system itself.
Structural concepts
An Android application in the development state is split into three major, conceptual, parts:
The Manifest (AndroidManifest.xml) – is the file which defines the application, describing all entities it has available for internal and external run The resources – which vary from constant variables (strings, integers etc.) to images and layouts (views) The entities definition – defined in Java (classes extending the core entities mentioned before)
Learning outcome 3
Android Development
Experimental development
Before I even started the study on Android I had an idea of an application inspired by some of my dayto-day troubles: waking up from a hard sleep. The application would be called “Annoying Alarm Clock” and it should provide a basic alarm clock that cannot be turned off unless you activate some of the sensors or hardware like:
Microphone – Scream loudly at your phone to make it stop Accelerometer – Shake your phone hard enough to make it stop GPS – Take your phone for a long enough walk to make it stop
Since the time was short and I wasn’t familiar enough to the environment, I did not set my focus on developing this application but, instead, I tried to understand and experiment with the libraries and sensors required to develop such kind of application.
Setup an activity
As mentioned before, activities are individual entities that are ran in the foreground and provide a user interface. Although in some development environments creating the UI can be easy, in the Android SDK this part is a bit trickier than expected. An activity (which ultimately takes the meaning of the UI) is constructed from two parts:
An XML defined layout using the Android XML Schema A Java entity (Class) which scope is to manipulate the layout, bind listeners and act accordingly
The XML Layout
Android XML Schema provides the developer with tons of objects and components that, I believe, can only be learn through more experimental work rather than reading the documentation.
Experimental development 4
Android Development
Working with HTML and CSS for the past years really conflicted when trying to understand the logic in the Android XMLS. The Android XMLS is similar to .NET’s ASP or Adobe’s FLEX which I personally do not enjoy.
The entity itself (Java)
Being already familiar with Java helped me a bit in understanding the coding logic behind the application, however, the rigorous way it is approached was very confusing. During the past years I’ve experienced with different programming languages and different frameworks and coding approaches and I really enjoyed the ones that gave you more creative freedom rather than standardizing everything (e.g. PHP instead of .NET, HTML and CSS instead of XMLS or Javascript instead of pretty much everything). Although the concepts in Android development are kept quite simple, the library it provides is bigger than expected and it encapsulates big handling libraries for quite simple tasks. I’ve been able to understand, learn and experiment with simple functionalities such as layouts, buttons, menus, transitions, events etc. and it feels better and better as I go deeper into it.
5
Android Development
Content Providers (Working with a local database)
As mentioned before, content providers are entities that are run in order to retrieve or write data. The entities operate individually and asynchronously from the central activity and can access both, local files, or databases. From the main activity (the foreground running entity) you call a content provider just as you would run another application.
Experimenting with the accelerometer
The accelerometer experiment was the one that cost me most of the time. In order to work with it and debug it I had to install several drivers and debuggers to be able to connect my Android phone and debug the application directly on the device. Knowing the variables changed by the accelerometer can easily describe when the phone is shaken, moved or rotated. The outcome of this experiment was a ball moving on the screen as the accelerometer variables are changed by phone motion.
6
Android Development
Conclusion
During my spell on learning the Android SDK and its concepts I have come to a conclusion that it has its ups and downs but, on overall, I think it is a friendly development environment. I think I have fulfilled my goal of getting familiar with the basics and this was done mostly through experiments. There were concepts or libraries which, in the beginning, seem very confusing and which I’ve managed to work with well, after all. The fact that an Android device provides much more “things to play with” than I regular PC caught my attention and opened my imagination. I believe that developing for these kind of devices is fun and it also has its opportunities to make a serious business out of it. On the downsides, I could mention that I had some difficulties understanding some of the features the SDK provides, however, this knowledge only comes with experience. Another solution for the future would be to try out PhoneGap, which is an HTML/CSS/Javascript framework to create portable mobile applications.
Conclusion 7
Individual study on mobile development for Android
Author: Robert Ontiu
University College Nordjylland
Android Development
Android Development
Individual study on mobile development for Android
Introduction
This report intends to present and evidentiate the process of learning the basic concepts on developing Android applications as well as the problems encountered on the way. The purpose of the process is not to create a final, working product but, instead, to try different approaches on the subject and experiment with the amazing functionalities the system provides. To start with, I personally believe that Android, as a software development environment has grown exponentially for the past years and it brings a new market in the area, offering amazing opportunities for software developers to easily create and deploy their products. Starting to learn Android development has been a good choice for me for two main reasons: It brings a new, ongrowing market for software developers eager to affirm and express their ideas and knowledge The fact that Android itself is an open-source product perfectly suits my beliefs that a product design by “people” offers a better experience than any other product designed by corporations (e.g. products designed to be marketed only)
Description
During the time spent on learning the topic I have focused my attention on understanding the concepts of Android, both abstract and concrete, as well as learning the core libraries the system provides while implementing some of them in experimental applications. Some of the information I’ve researched has not been new to me while, on the other hand, I’ve encountered some interesting concept s which were a bit trickier to understand.
1
Android Development
Learning outcome
To start with, the Android is built on top of a Java Runtime Library (JRE). While I was very familiar to Java, the harder aspects of learning became the understanding of Android libraries as well as the concepts of structuring the application.
Abstract concepts
In contrast to other development environments I have studied before, Android implements rigorous standards for both designing and coding your application. While on the design phase the system provides tons of components that are just to be added and bind to the application, the development phase has to follow structure standards and other abstract concepts in order to work properly. The most similar approach I’ve encountered before is the .NET development environment which I think, implements even more rigorous standards. One of the important aspects that caught my attention is that the system itself (Android) is user-centric (more details are to be found here: http://developer.android.com/design/get-started/principles.html). Some of the principles I remarked from this list are:
Use “real objects” (visual entities that can be manipulated by the user) Get to know the user (use previous actions to simplify tasks) Take advantage of the visual standards to make the UI look familiar
The architecture of the system is also something new to me and I personally appreciate and enjoy the way the system is implemented. In Android, each application represents a user of the system which is assigned permissions (through contracts) by the superuser (which is ultimately the person operating the system). Therefore, when you are designing an application, you have to think about the permissions you would like to acquire and create a contract to be sent to the end user.
Learning outcome 2
Android Development
Fundamental concepts
In opposition to other architectures, applications running on Android have more than a single access point (depending on the nature of the project). I can think of these “access points” as separate entities running individually and providing, each, a different functionality. They can be ran both, from within the application itself or, with proper permissions, from any other application within the system. The system provides the developer with only four types of functional entities (or access points):
Activities which are applications ran in fullscreen mode, providing an user interface and becoming inactive when they are closed or lose focus (minimized) Services similar to Processes in Windows or Demons in Linux do not provide an user interface and run in the background Content providers similar to Streams from .NET – are used to read and write content to internal storage or databases Broadcast receivers are entities that listen to system events and take actions accordingly
At a first glance a was a bit let down by the feeling that such a flexible system would impose such rigorous standards, however, after a peak into development a believe that they perfectly suits the principles and desired functionalities of the system and even more, they also feel as flexible as the system itself.
Structural concepts
An Android application in the development state is split into three major, conceptual, parts:
The Manifest (AndroidManifest.xml) – is the file which defines the application, describing all entities it has available for internal and external run The resources – which vary from constant variables (strings, integers etc.) to images and layouts (views) The entities definition – defined in Java (classes extending the core entities mentioned before)
Learning outcome 3
Android Development
Experimental development
Before I even started the study on Android I had an idea of an application inspired by some of my dayto-day troubles: waking up from a hard sleep. The application would be called “Annoying Alarm Clock” and it should provide a basic alarm clock that cannot be turned off unless you activate some of the sensors or hardware like:
Microphone – Scream loudly at your phone to make it stop Accelerometer – Shake your phone hard enough to make it stop GPS – Take your phone for a long enough walk to make it stop
Since the time was short and I wasn’t familiar enough to the environment, I did not set my focus on developing this application but, instead, I tried to understand and experiment with the libraries and sensors required to develop such kind of application.
Setup an activity
As mentioned before, activities are individual entities that are ran in the foreground and provide a user interface. Although in some development environments creating the UI can be easy, in the Android SDK this part is a bit trickier than expected. An activity (which ultimately takes the meaning of the UI) is constructed from two parts:
An XML defined layout using the Android XML Schema A Java entity (Class) which scope is to manipulate the layout, bind listeners and act accordingly
The XML Layout
Android XML Schema provides the developer with tons of objects and components that, I believe, can only be learn through more experimental work rather than reading the documentation.
Experimental development 4
Android Development
Working with HTML and CSS for the past years really conflicted when trying to understand the logic in the Android XMLS. The Android XMLS is similar to .NET’s ASP or Adobe’s FLEX which I personally do not enjoy.
The entity itself (Java)
Being already familiar with Java helped me a bit in understanding the coding logic behind the application, however, the rigorous way it is approached was very confusing. During the past years I’ve experienced with different programming languages and different frameworks and coding approaches and I really enjoyed the ones that gave you more creative freedom rather than standardizing everything (e.g. PHP instead of .NET, HTML and CSS instead of XMLS or Javascript instead of pretty much everything). Although the concepts in Android development are kept quite simple, the library it provides is bigger than expected and it encapsulates big handling libraries for quite simple tasks. I’ve been able to understand, learn and experiment with simple functionalities such as layouts, buttons, menus, transitions, events etc. and it feels better and better as I go deeper into it.
5
Android Development
Content Providers (Working with a local database)
As mentioned before, content providers are entities that are run in order to retrieve or write data. The entities operate individually and asynchronously from the central activity and can access both, local files, or databases. From the main activity (the foreground running entity) you call a content provider just as you would run another application.
Experimenting with the accelerometer
The accelerometer experiment was the one that cost me most of the time. In order to work with it and debug it I had to install several drivers and debuggers to be able to connect my Android phone and debug the application directly on the device. Knowing the variables changed by the accelerometer can easily describe when the phone is shaken, moved or rotated. The outcome of this experiment was a ball moving on the screen as the accelerometer variables are changed by phone motion.
6
Android Development
Conclusion
During my spell on learning the Android SDK and its concepts I have come to a conclusion that it has its ups and downs but, on overall, I think it is a friendly development environment. I think I have fulfilled my goal of getting familiar with the basics and this was done mostly through experiments. There were concepts or libraries which, in the beginning, seem very confusing and which I’ve managed to work with well, after all. The fact that an Android device provides much more “things to play with” than I regular PC caught my attention and opened my imagination. I believe that developing for these kind of devices is fun and it also has its opportunities to make a serious business out of it. On the downsides, I could mention that I had some difficulties understanding some of the features the SDK provides, however, this knowledge only comes with experience. Another solution for the future would be to try out PhoneGap, which is an HTML/CSS/Javascript framework to create portable mobile applications.
Conclusion 7
