Over the course of the semester, we have learned the basics of developing Android applications with the use of Xamarin. Xamarin is used for cross-platform application development, which cuts down on the time it takes to develop an application for both Android and iOS. My original idea for this final was to use the existing code from one of our assignments to develop an iOS application to see how easy the process was to use the cross-platform functionality of Xamarin. Unfortunately, after spending some time learning the iOS side of Xamarin, I realized that I needed to have a Mac computer to use this functionality. So, the focus of my final shifted from developing for iOS to developing in Android with the native IDE. I decided to download Android Studio and try to build some of the assignments that I had previously completed using this IDE instead of Visual Studio. Not surprisingly, I noted a lot of similarities between the two. However, I also found a lot of differences. Throughout this paper, I will discuss what I learned while using the Android Studio IDE.
The best way I felt to learn about Android Studio was just to start using the platform. So, I rewrote the first assignment from this course using that IDE. This approach allowed me to leverage the knowledge I had gained throughout the semester so that the concepts of using an entirely new IDE were easier to grasp. Before this, Visual Studio was the only IDE that I had ever used. Right away I noticed some similarities and differences between the two environments. I will discuss each of these in turn by area.
The syntax between the two environments shared more similarities than differences. In Xamarin we are using C# to write our applications, whereas in Android Studio we use Java. At the beginning of the semester, it was noted to the class that C# and Java were very similar programming languages. Throughout my research for this final, I found this statement to be correct. While there are subtle differences, the fact that I had learned C# before using Android Studio made the process much more manageable.
Below is an example shows the OnCreate() method from Android Studio and Xamarin, where we can see the similarities between the two. These two statements are practically identical, except for a couple of subtle differences. Microsoft, as we can see, uses Pascal case, whereas, in Java, they use camel case. Also, in the SetContentView() method, the Resources call is simplified in Android by just writing “R”. As I show more examples, we will continue to see an evident similarity between the two IDEs.
Building the layouts between the two IDEs showed similarities and differences as well. The first thing that I noticed was that in Android Studio, the Activities had two different layouts. For instance, say we created an Activity whose name was MainActivity. In Xamarin, we would have a layout named Main.axml. However, in Android Studio we would end up with a layout named activity_main.xml and content_main.xml. After conducting research into the subject, I found that the two had different uses regarding the layout. The activity_main.xml file has special tasks for using the floatingActionButton, tabLayout, and coordinatorLayout. The content_main.xml layout sits on top of the activity_main.xml layout and is used for displaying things that the user will see. In other words, this is where we add our widgets with which the user will interact. Also, when we would add more Activities to our application in Xamarin, we would have to manually add another layout. However, in Android Studio, it will add the layout automatically.
Another difference regarding layouts is the support of the ConstraintLayout in Android Studio. While working within Xamarin, we were exposed to several different layouts, including the LinearLayout, the GridLayout, and the RelativeLayout. What is nice about Android Studio is that it also supports the ConstraintLayout. This layout is similar to the RelativeLayout, where you can position children relative to their parents and widgets relative to each other. The main difference here, in my opinion, is the ease of use and flexibility. With the ConstraintLayout, we can use the designer to constrain a widget to a position relative to the screen and other widgets by clicking the circle on the top, bottom, left, or right and dragging the arrow to where we want the widget constrained. This layout makes it easier to design a UI that will look good on any screen size because the widget will expand and retract based on the constraint to fit the device on which the app is currently loaded.
I also found the responsiveness of the designer very different between the two environments. In Xamarin, when we started progressing with more complicated layouts, I found it easier to just write them directly into the XML. In Android Studio, I felt I could make more complex layouts with the designer, and they would respond the way I wanted. Another feature that I liked in Android Studio is that if you wanted to work with the XML directly, you could see the difference that it would make with the designer right away. This feature cut down on the time of flipping back and forth between the designer and the source, which made designing the UI a far less painful process.
Of course, the key concepts that we learned about layouts were the same between the IDEs. As noted above, you could work with the layout with the designer or directly with the XML. When we call the layout from the Activity, we do it from the SetContentView() method just as we did in Xamarin. Working with the landscape layouts is also the same, where we name the file the same as the portrait layout and stick it in a folder named layout-land. Having all of this knowledge up front was incredibly useful while learning to navigate through Android Studio.
When we began working with Xamarin, we learned a lot about the file structure for an Android application. And most of what we learned transferred over to Android Studio almost exactly. In both IDEs, as shown below, each contains a resources folder that, in turn, contains folders for the layouts, drawables, and values. For both, the resources folder also contains the subfolders for all the different resolutions used by Android. One difference between the two regarding the resources folder is where the AndroidManifest file is located. While working in Android Studio, I noticed that this file is located in the resources folder, whereas in Xamarin it is located within the properties of the project. Within the resources folder in Xamarin lives a file named Resource.Designer where the id for all our views can be found along with the associated memory address. In Android there is no such file. However, the id for all views is stored in the res/values folders where we can reference them through the R.id.name call.
Another difference when looking at the file structure between the two IDEs that I noticed was that Android Studio has this thing called Gradle. So, I did some research into what Gradle is and how it is used in the Android Studio environment. Gradle is the build tool that Google is currently using for Android Studio. The following figure from the Android Developers website shows that Gradle is used to manage the Compilers and APK Packager. In this graphic, it shows that the Compilers convert your source code into Dalvik Executable (DEX) files. Then the APK packager combines those DEX files with the compiled resources to generate a single Android Package Kit (APK). The APK packager then signs your APK with either a Debug or Release Keystore before your app is ready for deployment and testing.
The key takeaway from this section is that most of the underlying pieces of the file structure are identical between the two IDEs. The real difference is the build system that the IDEs use to compile and deploy the application. In the end, the two wind up in the same place. With Xamarin, you still wind up with an APK that is signed by either release or debug builds. The difference is that Xamarin uses MSBuild to complete this task and Android Studio uses Gradle. However, this is a simplified conclusion, and by looking at the documentation, I can tell there is a lot more to this subject.
While working through Android in Xamarin, I got very comfortable using the Delegate method when handling events. I came to find that this is a .NET C# way of handling events and that Android Studio was a little different in this area. While working with Android Studio, I adopted the Anonymous Classes technique to handle the click events. This way of handling the click event is actually closer to the Anonymous Delegate technique from C# than the Delegate method that I had used throughout the semester. This similarity comes from the fact that you can write the event handler straight into the OnCreate() method, instead of writing the event handler outside of the OnCreate() method and then wiring them up. I found the Anonymous Classes technique in Android Studio to be an easier way of handling the event. To illustrate the difference, below I show a snippet of my code from the two environments that are doing the same thing. However, I think the way I wrote it out in Android Studio is more straightforward to read and easier to understand.
Throughout the semester, we used intents to send text messages and emails as well as to start new activities. This process of using intents is almost identical between the two environments. The same idea of explicit and implicit intents applies to both. This idea means that we can tell our application to do something, like send an email, but not be worried about which application it uses to complete the task. On the flip side, we can have our application start a new activity and tell it exactly which activity we want to start. The first example would be an implicit intent, where the latter would be an explicit intent. These same principles apply to both the Xamarin and Android Studio environments. As you can see from my two examples below, creating intents and passing data to them is practically identical. We use the PutExtra() method to pass data through the intent. And if we wanted to get the data back out of the intent, we would use the GetExtra intent as we used in Xamarin.
I found some big differences between these two IDEs throughout this experiment. Most notably, for me, would be the ease of use between the two. I caught on to using Xamarin a lot easier than I did with Android Studio. This situation occurred because I have had a bit of experience working inside Visual Studio which made doing things like debugging far easier to learn. With Android Studio I was learning an entirely new IDE that I had never used before, along with a programming language (Java) that I had never used before. Therefore, I did not get nearly as far with learning the IDE as I would have liked. However, throughout the process, I believe that if I were to build another Android application, I would probably prefer to build it in Android Studio.
Android Studio was challenging to learn because I was working with an entirely new IDE with which I had no experience. However, I felt the functionality was better than Xamarin’s. In Xamarin, I continually had problems where I would make changes in my layout through the XML, and it would not save correctly. If I saved the file, closed it, and reopened it, sometimes my changes would not be present. I don’t know why this occurred, but it drastically impacted the development time for my applications. I spent far more time messing around with the layout than I did writing the code my application. In this respect Android Studio was far better than Xamarin in my opinion. Building the layout in Android Studio became much easier, and I had far less problems which allowed to focus more on writing my code.
In the end, if I were to be developing an application solely for Android, I would choose to use Android Studio over Xamarin. However, I also realize that Xamarin carries with it an immense benefit when it comes to cross-platform development. Though I have not developed an iOS application, if I were trying to do cross-platform development I would probably choose to use Xamarin. Either way, I am glad that I took the time to learn another IDE to have the experience under my belt.
Learning how to use Xamarin and Android Studio has been a great experience. I am glad that I now have some more tools in my toolbox from which I can leverage as I go out in my career. I look forward to using these technologies more and more as I progress in my knowledge. I want to use Android Studio even more so that I can learn more about the tools that I did not have the time to experience. I am looking forward to new opportunities and new learning experiences as I continue to work with these two environments.
If you enjoyed this post, please share on your favorite social media site by clicking the buttons below.