With the passing of time more and more options rise of how to create GUI for an Android [and not only] Application. You know – if you are a software developer doing the front-end part of some service, you must include Android because of the big percentage of the market share of this mobile OS. Here is short list of the technologies or frameworks the you could pick.
There are several options for coding Android user interfaces – several, provided by Google themselves and a few from other companies. Besides the views build-into Android, Google is also developing support APIs and several implementations of their recommended design theme – Material Design or the simple UI libraries.
Java/Kotlin + XML
The oldest and the most popular way is to implement the UI with XML and to wire and glue it to logic and data with code. Google are migrating away from Java programming language probably because of the legal fight with Oracle. There is another reason, and it is the lack of control. Google have invested and is a partner with JetBrains to jointly develop and improve the Kotlin language. They could change it how they like it. Probably they will not have any legal issues. Google also moved to their IDE for Android Development Core – IntelliJ.
The latest framework – similar to Flutter & Dart, Java FX, Swift UI and many others is JetPack Compose. You could declaratively write UI that compiles or trans-compiles to the core UI components at pre-production time.
Having a web page and no natively packaged app is an option, that will directly target not only Android, but all platforms. Having an app could bring improved user experience, better SEO, marketing, popularity. But, having/being a web page, automatically makes your service/product accessible to whatever device, operating system or some something else – any company decides to create, as long as the new “place” has a browser. And this will happen without any additional work from the app developer or from the platform inventor.
Progressive Web Apps – are some additions in the APIs – implemented in browsers considered “modern”. These new features allow you to offer the user to “install” the web page to be integrated into the Operating System as a program. In reality the Operating System launches the web site in a normal browser – just – with a missing address bar.
The requirements to the web site are few:
- You must serve the content securely – over HTTPS
- The web page should register a Service Worker
- The service worker has the possibility to cache offline specific rarely changed resources and the offline page. The offline page is opened when the browser’s standard cache is gone and the Internet Connection is off. Ideally the offline page is the same as the page opened when connected – just – with different message or some offline data.
- A link to a manifest file – that will describe the app – icons, name, description and other settings.
You could read more about PWA in – “Convert any site to an App – Progressive Web App“.
The embedded web view is an option for data displaying and an option for basic functionality. I [Toma Velev] have a personal experience on application that at the peak – the app was reaching more than 50 000 active users. It was one of my most successful android apps. It contained several simple screens and one of them – the most important – was with a web view. The Web View was opening a web site and I was adding missing functionalities that then the web site lacked at that time.
I was using the same technique that Cordova uses. Just – the bridge layer between the browser and the app was/is thin as a thread – compared to an ancient sized tree of that framework (or other). The Web View User Interface Component is lighter than the full fledged browsers for practical reasons. And when most of the features you need are just data manipulation – there is no need to overuse resources.
There are several cross-platform bridges that try to evolve, reshape and improve the idea of Cordova. What Cordova lacked is Good User Interface Components. It delegated this to the Web/CSS Frameworks, that have endless options. Some of the frameworks try to remove the web and use the build-in each platform user interface components. Others use self-drawn widgets.
Native Script started with the same idea as Ionic. It is subsidiary of the former Telerik company – now owned by Progress Software – that also offers a lot of components – mobile, for desktop browsers, with backend integrations and more. They evolved and are offering alternative view layer. With NS you could write the same code, logic and styling and have several view files containing alternative visual components. You could write web specific code with HTML and mobile code with XML. The XML option does not use Web/HTML Element but a native components as rendering widgets.
There are also options for the front end framework and language. Native script offers
- vie.js or
- angular framework
As code architecture & base framework. As a programming language for the business logic you could pick
React native is a child of Facebook. They ditched the Web view approach years ago and are using platform components for the user interface. The react native developers even replaced the bridge that passes the logic to the screen, the engine, with their own. Having something custom and specific for the task always helps.
One of the biggest features that many other native frameworks are missing is code push – the ability to deploy code to production without going through the app stores. This possibility may be partially killed (especially for Apple and their closed ecosystem).
Xamarin is a framework with the same common cross-platform idea. It started with mono (open source c# library). Microsoft purchased it and included windows phone (discontinued), desktop windows and universal windows platform in the produced target executables.
Android underneath is Linux OS. Many companies and projects that already have implemented the heavy work of writing native GUIs, are able to port it to Android. Google offer Native Development Kit for transforming the code for usage by Android App. Such companies and projects could be especially Game oriented. Truly native code is meaningful and is a must for performance in there.
Flutter is the Google’s toy that brings a native GUI Drawing Library – Skia – to Android. It distances itself from the other cross-platform toolkits in the components it uses. It draws everything itself – and that has a good side and a bad. There is no bridge and overhead when a widget need customization. But, when a native to a platform behavior is required – an application developer must wait the Framework developers to bring it, or do hack-y workaround.
Qt is Open Source Framework for all the platforms. Using a native language as C++ makes it perfect for applications with heavy processing. Some of the areas could be photo, video, sound or some kind of manipulation based in hardcore math. C++ is closer to the hardware and could potentially result in better performance. The bad side is, Qt team must have ported every API to the different platforms before the application developer could start doing his thing.
Unity is Game Developing Platform. The “IDE” is actually a designer because games are very graphic intensive. The actual code is small scripts that plug, move, inject the interactivity of the visual elements.
There are probably other GUI toolkits, but these are enough options for today. Diving in too much options kills the productivity. Go, pick one the express yourself.