Previously I wrote an article for getting your own copy of the AOSP source, AOSP: Download, I thought before we go a head and build a ROM it would be worth having a quick run through of the AOSP architecture so we can understand where we should be making our changes if/when we want to.
Below is the high level architecture diagram of the AOSP provided by the AOSP website.
As you can see we have multiple layers within the system, they are:
Used primarily by developers to create Android Apps.
This layer allows for Inter-Process Communication (IPC). That is it allows Apps to cross process boundaries, similar to COM in Windows.
A collection of co-operating services which should be thought of as modular focused components. There are two groups of services, as shown above, System and Media services.
Hardware Abstraction Layer (HAL)
As the name suggests this is an abstraction layer between Android and the underlying Hardware. The HAL defines an interface that must be implemented by hardware vendors.
Android is built on top of the Linux Kernel and as with most distributions Android patches the Kernel to meet its needs.
This is a very quick introduction to the different layers of the AOSP and I’ll go into more detail for each layer in future posts and as we go along but I think this gives you a good idea of what to expect. Next we’ll build a ROM and run it in an emulator.
I wrote a Bitcoin Node setup post recently (hopefully you had a go?) and thought I’d show you how to setup an Android Open Source Project (AOSP) development environment and how to download the AOSP.
This tutorial will be for a Ubuntu 18.04 machine only. Other systems should be ok, such as ElementaryOS or newer versions of Ubuntu, but I’ve not tried any other. Feel free to get in touch if there is an OS you’d like me to demonstrate or if you’re having any issues
First things first, open a terminal using ctrl+tab+t and type the following:
sudo apt-get update
sudo apt-get upgrade
Once they are done we will have an up to date machine and should be good to get stuck into setting up for AOSP.
Our plan is to get the official AOSP source on our machines, if you want to check it out now you can visit https://android.googlesource.com/ for more on what we’re going to download.
If you popped by the link you’ll see there are a lot of repos available to you. Don’t manually download each one, we’ll get to that using the repo tool.
We need to install some packages to get our machine ready, so run:
Same as above and worth considering is using the -j flag with your sync, it allows you to sync repos in parallel. By default it will do 4 parallel downloads.
To get a different version of the AOSP visit https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds and pick the one you’re after. Simply update ‘android-9.0.0_r50’ above with the Tag of the build you choose.
Great, so now we have our Android™ repos downloaded.
We’ll leave it at that for this post but I’ll be putting another out soon where we will build and create our own Android™ Distribution to run on an emulator.
I mentioned in a previous post that I had become a Xamarin Certified Mobile Professional (check it out for an introduction too) which I really enjoyed getting to and learned a lot of about Xamarin, .Net, and the platforms involved. I’m going to start sharing more of what what I’ve learned starting now.
For this post as the title suggests we are going to look at the MVVM pattern…
MVVM is a software architecture pattern and is a variation of the MVC (Model-View-Controller Pattern). The acronym stands for Model-View-ViewModel, which identifies the key components within an MVVM targeted app but we’ll get to that.
The pattern is concerned with helping us decouple our business and presentation logic from the user interface.
Why would we want to do this?
By providing that separation between the components we can improve our development by allowing different teams (such as the design team and the development team) to work to an agreed contract and develop their own components independent of each other.
As the name suggests the Model-View-ViewModel pattern has 3 core components, Model, View, and ViewModel. As they say a picture (diagram in this case) paints a thousand words so hopefully the diagram below gives you an idea of the relationship
View: Knows about the ViewModel
ViewModel: Knows about the Model but does not know about the View
Model: Does not know about the View or ViewModel
As you can see the ViewModel provides a layer of separation between our View and Model components and through the use of Data Binding we can decouple our ViewModels from our Views. By developing our apps in this way we get quite a few benefits:
Adaptive: We can take old Models and adapt them for use in our apps through our ViewModels. e.g. models developed for a web app that aren’t suitable for mobile can be adapted via the ViewModel to provide our Views what they need.
Testable: Our unit tests can be developed and maintained easier as our C# code is separate from our UI.
Decoupled: We reduce the dependencies between the components and so can update them independent of the others, providing of course we continue to adhere to our contracts.
Now that we have an overall idea of MVVM lets take a look at each component.
The first component we’ll look at is the View. It is responsible for what the user sees, the structure, layout, and appearance of each Page. Within Xamarin we have two files, a .xaml file and a .xaml.cs file, which together define our views (or pages). As the names suggest our .xaml file will hold our Xaml implementation of the UI and the .xaml.cs file will hold our C# code-behind.
So we can develop our Views using either Xaml or C#, with the use of the MVVM pattern in our apps we aim to do everything in Xaml and have the bare-minimum C#, however in some cases we may need to use C#, such as with animations.
One question you may have now is if we aim to put as little code in our View code-behind how do we allow users to do anything, such as fill in a form and submit it?
For this we have Commands, if a control (an visual item) supports the ICommand interface we can register to it to a property on it’s ViewModel (which must implement this interface). So when a controls ICommand action is triggered the associated property on the ViewModel is triggered. Additionally there are features called Behaviours, these can be attached to an object in the view and wait for either a command to be triggered or an event to be raised. Once the behaviour has been triggered it can then either call the ICommand property or a method in the ViewModel.
Our ViewModels provide Properties and Commands for our views to attach to through the use of Data Binding and through this relationship it can flow the UI presentation logic to the View without needing to know about the View. This is done through the use of the INotifyPropertyChanged interface which uses the OnPropertyChanged method to notify the View that a change has occurred, making apps very responsive if implemented correctly.
Think of this relationship as the View is used to define how the functionality will be displayed and the ViewModel, through the use of properties and commands, defines what will be displayed in the UI.
Looking at the diagram above again you can see that our ViewModel sits between our View and our Model, this is no accident. Through the ViewModel we can co-ordinate our Views based on based on our Models and updated our Models based on our Views through the ViewModel, providing that layer of separation between the two components. In some cases the ViewModel will expose the Model directly to the View but we also have the control to perform data modification in the ViewModel to meet the needs of our expected presentation design. A very simple example could be convertign data from one format to another such as from lbs to kgs.
As I mentioned above we perform the communication between our Views and ViewModels through DataBinding. Data Binding allows us to hook our UI elements to properites in our ViewModel and then provide either one or two way communication between the two components.
For the ViewModel to View communication to occurr the relevant property must raise the property changed event, called OnPropertyChanged. In order to do this a ViewModel must implement the INotifyPropertyChanged interface and raise the event when a relevant property is changed. By doing this whenever the property is changed the relevant UI element will automatically be passed the new value to display. Providing up to date information to the user.
If you have a list or other collection it is a bit easier to perform that communication, use the data structure ObservableCollection<T> and much of the work is done as it implements the INotifyCollectionChanged interface. All you need to do is hook it up.
Lastly, we have the final component, the ‘Model’. This is quite straightforward, the Model is any class not directly associated with the visual aspect and can be viewed as representing the domain model.
This generally involves our data model and our business and validation logic. Examples of Model level entities are Plain Old CLR Objects (POCOs) but also include Data Transfer Objects (DTOs), entity, and proxy objects.
We primarily use this component with services and repositories for data access and caching.
So there we have it an intro to MVVM and the core components. Our View handles the formating of what the user sees, our ViewModel what will be seen, and the Model helps to organise and process.
The pattern is very popular within the mobile development domain and I highly recommend you give it a go if you haven’t already to see if you could benefit from it.
So just wanted to write a post as I just got my Xamarin Certified Mobile Professional certification today, very happy with that.
Very Quick Overview of Xamarin:
Xamarin is a cross-platform mobile development framework for developing Android and iOS apps. It allows a huge amount of code reuse through the use of the Xamarin.Forms framework and when coupled with UWP allows for all 3 major platforms to have an app developed at a huge reduction in cost, time, and effect (the magic 3 in my mind). The best bit is that it is all done using C# (and XAML if you want) and makes use of native APIs for those platforms. Xamarin tries to provide a wrapper that you use to do what you want but the underlying framework calls into the platform-specific APIs, obviously this doesn’t work in all cases but they recommend you can get anywhere from 70-90% code reuse.
I’ve been using Xamarin (not as part of my day-to-day job) for quite some time, about 2 years on and off I think. My goal has always been that I will move into mobile development (…again (my first job was as the Android developer within an R&D team)) and for quite a while I only had the time to do any mobile development in my spare time, which there was not a lot of and even less now. But to be honest it’s more than likely I didn’t make as much time as I could’ve to speed the process up… the lies we tell ourselves hey.
My introduction with mobile development was through Android (day to day job back in 2014/2015) and I had a Windows Phone for a few years so I made some apps for that and put them up on the Windows Store. Though nothing to shout about tbh, for example, the first was the classic Torch app, though one I was quite happy with was a Pokemon guessing game where users would guess the name of the Pokemon back on the silhouette (basically the “Who’s that Pokemon” game in the show). A few people seemed to like it, wouldn’t go looking for it though in case you were interested it’s not available in any of the stores. No doubt there are plenty of good alternatives, I even contacted the Pokemon Company the find out if I could somehow develop the game properly…. as you can imagine they were not interested.
Anyway coming back to Xamarin, when I heard about it I thought it was brilliant, started listening to the Xamarin Podcast, with James Montemagno and Pierce Boggan (check it out here), and attended one of the Xamarin Dev Days (which was really good and even got to have a go on the Hololens which was cool) though they don’t seem to be happening anymore. As mentioned becoming a mobile developer, specifically a Xamarin developer, has been in the works for a while now and I didn’t seem to be making much in the way of progress (always something taking up the time, I’m sure you’ve experienced similar problems right?) but a few months ago I just decided I was going to go for the certification and I would get it. After some time and effort, today is that day, if you are thinking about doing it yourself I highly recommend just starting the material on the Xamarin University website. Get through it as and when you can and before you know it you’ll be making a nice amount of progress. Even if you don’t want the get certified still worth a look, the content is free.
I’ll be releasing some material over the next few months about how to get started and possibly some other tutorials. I do have some other Introductory content coming up but I’m looking to target that in a more general sense using C++ and C#. Should hopefully get the ball rolling soon.
Thanks for reading and if you have any comments feel free to leave them or send me an email via the contact page.