One of my final assignments at University was to create a mobile app using Xamarin.Forms. With no specific app design specified, we were free to design and create our own apps. Our only requirement was to apply the MVVM design pattern to our project.
I chose to develop an app related to vexillology (the study of flags) and those interested in flags and collecting them. The app would allow users to mark down flags they had collected, flags they wanted in the form of a wishlist, and collections of flags that users could strive to complete, such as Scandinavia, or the British Isles.
Instead of including every flag image individually in the app, I opted to use Wikipedia’s image API to grab a PNG of each flag, and this is displayed throughout the app.
Xamarin
UI
The main method of navigation for the app is to use the sidebar. It contains several pages that the user can visit, as well as the ability to logout of the app.
Flags
The app opens to a simple homepage that contains 3 lists of flags. Featured and random flags are both randomly generated, but recommended flags is generated based on the flags that the user currently owns. This is elaborated on in the API section of this page.
When clicking on a flag, the user is taken to a flag page which contains further details on the flag, including a description, any aliases that the flag goes by (e.g. Union Jack for the UK flag, Tricolor for France, etc). This information is grabbed through an API call.
An unfortunate issue with using Wikipedia’s API for the flag images is that they store each flag at its real proportions. This means that for some flags, such as the Union Jack, the image at the top does not take up much space, but for flags like the Swiss flag, which has a 1:1 proportion, the layout is much different.
The green + floating action button on the flag page allows a user to add the flag to either their flag wishlist, or their owned flags.
It also has the potential to be easily extended to allow user created collections too.
Collections
As well as viewing individual flags, users can also view collections, both collections that they can directly add to, as well as collections that they can aim to complete. Owned flags is an example of the former. When a user marks a flag as owned, it will appear in the Owned Flags collection.
The collection page is simple; it shows all the flags included, as well as an orange “edit” FAB that when pressed, shows a small “delete” FAB for each flag to remove it from the collection. The edit button only shows for user-owned collections.
The other type of collection is the type that a user can strive to complete. For example, the British Isles, or Scandinavia.
The “MARK AS COMPLETE” FAB adds all the flags in the collection to owned flags, and comes with a confirmation box to prevent accidental pressing, which for larger collections could be very frustrating for a user.
When a collection is opened, each flag image and name is pulled via the API, and for larger collections (e.g. Africa) this can be quite slow, so the implementation of lazy loading would be a good next step.
Searching
The search page allows a user to search for both flags and collections. The SQL query will compare the search term to the name, alias and tags of a flag. This means that by searching for “uk” you will not just see the UK flag, but also all flags associated with the UK, such as Saint George’s Cross and the Scottish Saltire. They are found by the search function as they have a UK tag. The results also include Ukraine, as it checks for partial matches for names too.
User Pages
The app also includes a page for both a user profile, and a login form.
As you can see, it has the capability to show a username, location, profile picture (although a placeholder for this example), as well as the number of owned and wishlist flags. This currently only displays for the logged in user, but takes the username as a parameter so can very easily be extended to show other user profiles than that of the current user.
The final page is the login page, which then checks the login details against those stored on the server. They are of course encrypted, but this is elaborated on in the API section.
API
Structure
The API is made from a Deno Oak server that is hosted on a virtual Ubuntu machine via Codio and was made to follow REST principles. The server contains a database with all the flags, flag collections, and users.
The flag table contains a column for the flag’s respective Wikipedia API url for getting the flag image. This makes it unnecessary to store large collections of flag images on the server, saving space.
User passwords are stored in a hashed form with a salt via bcrypt. This helps prevent hackers from cracking passwords should there be a data breach.
Models
The database has 4 tables:
- Flags
- Collections
- CollectionItems
- Users
The above ERD shows the initial database design, but some extra fields being added to Flag during development to display more information. CollectionItem is used to assign a flag to a collection by associating both IDs as foreign keys.
Functions
Other than functions that simply execute SQL queries to grab data, the server also has functions to generate a random selection of flags, as well as a tailored selection of flags based on the owned flags of the user. This is used to create the Trending, Recommended and Random flags sections on the app’s home screen. Tailored selections are made by checking the tags of each flag a user owns, and other flags that share these tags are then added to the recommended collection. It also makes checks to ensure already owned flags are not re-recommended to a user.
Finally, a search function was made to allow the user to search for both flags and collections in the app.