In the 1990s, there was a piece of software for the Acorn RISC OS range of machines called SBase. The software was one of the most stable, intuitive, and above all simple-to-use applications. I was surprised many years later to find out that this was not down to unit testing, A-B testing, or anything like that. The reason was that before a single line of code had been written, absolutely everything was written by hand first. Not code (this would not be a good plan), but a detailed storyboard and flow.
After a month or so of planning, the work of coding began. However, as the author knew what would go where, the final development time was much less than the time it would have taken, had he just sat down and started coding.
There are quite a number of different design templates freely available for download (a quick search on https://images.google.com/ will show them). The following template will be used in this book:
For each new view, a new design will be drawn. While the app will never be a one-to-one representation of the design, it should be close and give an idea of how all sections would work together.
It is also a good idea to use piece of flowcharting software when creating a flow. Again, there are plenty of pieces available, but through trial and error, one of the best that I have found is called the yEd Graph Editor (http://www.yworks.com/en/products/yfiles/yed/).
When creating any piece of software, it's also a good plan to have a shopping list of the features that you would like to see in the final application.
A messenger – a shopping list of features
The shopping list should feature everything that you want in the app rather than everything that you think should be in the app. If you have a large budget, then the shopping list can be longer. Remember, the longer the list, the larger (and more complex) the application.
The basics of any messenger application UI comprises of the following lists:
Contacts
Add and remove contacts
Message composition, add sound, and pictures
Message summary
Message display or text to speech
Message delete
Login/register/forgotten password
Forced synchronization
The following are a few details about the basics:
Contacts can be from Facebook or your contacts, and should also provide a summary of the contact
Messages need to be entered via a keyboard or speech to text (STT)
Messages need to be able to include pictures (not video) and sound
Message notifications (new messages) are required
Forced synchronization causes the app to download all messages and contacts from the server
Speech to text and text to speech
Speech to text is a vital addition to most applications to facilitate those who are visually impaired. These facilities are available on all mobile platforms, and the inclusion will greatly improve the scope and range of users who can take advantage of your new app.
Speech to text is not the same as adding sound to a message; adding sound is different.
While Android is a very open platform that allows users to create their own apps for messaging, iOS is very prescriptive over what you can and cannot do. For example, to create a text message, you must use their text message service and software. This is fine, except that it ties you in strongly to what Apple provides, and doesn't give the end user any different an experience; so why should they bother using what you have over what Apple supplies?
To remove this requirement, a web service can be used. The use of the web service gives a number of advantages:
This final point is of great importance for this application.
Cross-platform considerations
As the name of this book includes Xamarin, and you are reading this, you will be aware that we are using C# for the core language. This will already be giving a massive advantage in terms of code sharing (for example, all the data services, SQL, and core code will be the same, irrespective of the platform), and also by using one of the more recent additions to Xamarin. It also means that the user interface can be shared by using Xamarin.Forms.
We can also swap between devices. On my desk, I have to handle a range of Android devices (tablets and phones), a couple of Windows Phones, a couple of iPhones, and an iPad. At any given time, I may have two of the phones on me, and want to use the app on either of the devices. Not only will the data structure need to be the same but ideally, a similar user interface is needed. This is not to say that each platform version cannot make use of some specific tweak on each platform, but the overall experience needs to be the same.
A secondary aspect to having a cross-platform application is to have a common settings file. All three platforms store user data in a different (and largely incompatible) way meaning that for personal data and app settings, a common profile needs to be established. This can be achieved either online, offline, or both, each having their own advantages and disadvantages:
Obviously, from a portability and usability point of view, having both as options is the best way forward; however, synchronizing changes may be an issue: which is the newer settings file?
It is no longer acceptable to have apps run in a single language. While it was the norm to say, "Hey! I'm English, so everyone can understand English" a number of years ago, there is no valid reason why that now needs to be the case, as all devices are able to localize given the correct language file.
The issue though is that to have every language covered would cost a fortune—many (human) language translators charge between £50 and £100 per hour (at the time of writing), so unless you're part of a larger organization with deep pockets, this can be ruled out.
Online translation services
The next consideration would be to use the likes of Google Translate for the language files used within one version of the app. This is not a bad idea but has a simple problem: though the likes of Google Translate are getting much better, it fails to recognize the context of a sentence so the translation may be incorrect. That said, if the translation is for a message 3 of 10 (stored as message %0 of %1 in the localization file), the returned translation to German would be correct.
This allows translations to any language covered by Google (or the translation service you choose to use).
The only remaining issues are storage of the translated messages, and having them as usable across all platforms.
Consider how Android and iOS store localized strings:
iOS: The text for translation is stored within the language file like the following code:
Android: This is more in line with a standard XML format, as shown in the following code:
Android is closer to a standard XML format while iOS as a Dictionary<string,string>. The two are not easily translatable and really, there isn't a simple, cross-platform way to translate text.
However, there is a way around this issue, which also means that should Google add further languages to their system, further language files need no longer be created. The only caveat is that it requires at least one language file to store the translation data in a database on the device and on the server (for others to use).
While this may be initially slow for grabbing the translation file from the server, it won't be slow later on.
The internal data structure
Windows Phone, iOS, and Android all come with an implementation of SQLite (though Windows Phone does require the package to be installed via nuget). This means that we can have the same data structure for all platforms apart from being able to match up to the server with minimal issues. The code for accessing the databases will be covered in Chapter 5, Data, Generics and Making Sense of Information; here we will discuss the data table classes.
Any database can be considered as a series of disparate objects that may or may not be linked. Each of these objects is an entry in a data table.
Consider the following example of a book, author, and publisher:
The Newton-le-Willows Community Library has a hundred books on Android development. For argument's sake, they have only one edition and a single author for each book. Each book has the following information stored on it: the ISBN, price, author, publication date, and publisher.
The ISBN number is unique to each book, so it is never replicated making it perfect as what is known as a
Primary Key. The author may have written any number of books (not only on Android, but possibly in Chemistry and the UK Armed Forces between 1960 and 1965, for example). A name is also not unique—I went to school with three people who had the same name as me.
The publisher too, will have a table containing information such as their address.
In terms of a database structure, the publisher and the author will have what is known as a one-to-many relationship with the book (the meaning is literally that—one publisher or author to many books) going FROM the publisher or author table TO the book. Going FROM the book TO the author or publisher shows a many-to-one relationship.
To complete this triangle, there will be a relationship between the publisher and the author. As the publisher is a single entity using multiple authors, it will have a one-to-many relationship with the authors.
The ISBN number will have a one-to-one relationship with the publisher and the author.
The messenger data structure
For each table, the key data stored needs to be defined. We have, in our application, a simple set up:
The message
Contacts
Backend storage
The language
Each of these will need defining.
A message contains a number of pieces of information
The previous message Id is important for message threading. The first message in any thread will have a value of -1. It is then just a case of moving through the message identifiers to correctly thread a message.
Attachments can be either an audio file or an image. It is never a good idea to store these on a device within the database, as it leads to massive slowdown of the application (SQLite was never designed to store BLOB (Binary Large OBject) data types).
Contacts are anyone (including you). A contact can be anyone invited to share in the app with you; it can be read from your mobile device directory or obtained via the likes of Facebook. Each contact will have the following information:
Contact ID
Name
E-mail
Phone number
Last-used date
Username
Each message is linked to another message as well as to a contact.
While it is fine to have storage on the device, there needs to be an external server somewhere. Currently, there are two main players when it comes to external servers if you are unable to host things yourself. They are Microsoft Azure and Amazon. Both offer the same sort of facilities, but given that Xamarin uses the .NET framework, it makes slightly more sense to use Azure.
The configuration and setting up of an Azure service is covered extensively in Chapter 14, Bringing It All Together.
Making sure the messages get through
Part of ensuring that messages get through as soon as they are sent is to use a push notification. Essentially, this is sent out from the server to the application. Unfortunately, the procedure for getting this to work is not the same for Android and iOS.
For Android, push notifications are a simple affair, as shown in the following steps:
Register the application with Google and obtain an API key.
Once you have this, go into the Azure portal, click on Mobile Services, select the service name, and then select Push.
To obtain the key, go to https://console.developers.google.com/start, and click on Create Project. Enter a new project name. After sometime, the project will appear on the console.
Next, select Add an API and switch on the Google Cloud Messaging for Android option.
Now select the credentials and create a new Public API access key. You will see the following displayed. Over here, select Server Key:
After this point, you will need to just create a new key by selecting Create:
Once the API key has been created, copy and paste it onto the Azure push services page (shown in the following screenshot):
Once complete, select
Save and Android is set up, server side, to send a push notification.
For push notifications to work on iOS, you will need a valid iOS developer account with Apple (currently this costs $99 per year). Assuming you have such an account, log in.
If you already have a developer profile set up, skip to the Creating and configuring for push notifications section.
Creating your iOS profile
The certificate is your digital signature that can be used for any application, for any given team. The use of certificates enables developers to work on different teams and still have a valid signing certificate. Creating a certificate is simple enough:
Click on your Applications folder and navigate to Utilities | KeyChain Access.
From the Menu bar, select Certificate Assistant | Request a Certificate From a Certificate Authority… (as shown in the following screenshot):
Once this has been clicked, you will be presented with the following window:
Fill in the User Email Address using the address that the Apple developer account is registered with.
Click the Saved to disk radio button.
When these have been filled in, select Continue. After a few moments, you will be asked where to save the certificate. Give the certificate a meaningful name and save. You can now minimize the Keychain Access application.
You now need to upload the certificate. Again, this is simple enough. Log into your Apple developer console (https://developer.apple.com/):
Click on Certificates, Identifiers and Profiles, and select Certificates.
Click on the Add icon.
You will be presented with the options shown in the following screenshot:
You will need to create at least an iOS App Development and an App Store and Ad Hoc certificate.
The process for creating either of these certificates is the same. Select the certificate type, and click on Continue.
You will be presented with an information page that covers how to create your certificate (performed in the preceding steps). Click on Continue.
The next page allows you to upload the certificate you previously created to the Apple Developer portal. Click Choose File, navigate to where you saved the certificate, and click on OK to upload.
Once the file has been selected, click on the Generate button. After a while, the certificate can be downloaded. Download and double click on the certificate to install.
You can check whether the certificate has been installed by checking the Keychain Access application.
Creating and configuring for push notifications
We now have to create a profile for our application. On the developer portal, select Identifiers.
Select the + button to create a new app.
Fill in the
App ID description (this is just a name for the app).
Add an explicit app ID. This is recommended to be a reverse, domain-style string (for example, com.packt-pub.messenger).
Towards the bottom of the page, you will need to select Push Notifications.
Once complete, you will be presented with something similar to the following screenshot:
Once you are happy with all the selections, click on Submit.
Next, a certificate has to be generated for the notifications. If you're used to creating a certificate, generate two—one for development and one for distribution. If you're not, follow the instructions used for generating your initial certificate.
Select the app created from the App IDs page on the developer site (as seen in the following screenshot):
Select Edit.
Go to the section marked Push
Notifications.
Starting with the Development SSL certificate, click on Create Certificate and follow the on-screen instructions. When requested, select the development certificate created in step 7.
Once generated, download the certificates and double-click to install.
Exporting the certificate for Azure
The final step for creating the push notifications for Azure is to export what is known as a .p12 file. The steps for exporting the certificate are given as follows:
To access this, start the Keychain Tool, and locate the freshly installed development push notification entry (highlighted in the following screenshot):
Select
File | Export and give the file a name. Then click Save, as shown in the following screenshot:
This needs to be imported into Azure. As with Android, go to Mobile services | Push, and move to the Apple section:
Click on upload, and upload the .p12 file you have just exported from the keychain tool. Ensure that Sandbox is selected when requested. When complete, you will see the following screen:
Azure, iOS and Android push notifications are now set correctly on the server side.
Adding packages to your application
For the application to be able to access the Azure services, it requires an additional package. You can manually create it, but it is easier to use the NuGet package. I will cover this in detail in Chapter 3, Making It Pretty and Logging In.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
Filter
