By virtue of using a mobile device, you will have used a messenger app of some description or the other (as well as any number of other apps). As time has moved on, so have the apps. For the humble messenger software, you can now add sound, video, and audio, and have it extend over many messages (a message was traditionally 160 characters, as it was only used by telecom operatives to send small messages informing others of their progress or a fault in the system). How did the apps metamorphose to the apps we have today? The answer is simple—planned changes.
In this chapter, we will cover the following topics:
Application planning
Application setup
Creating the correct provisioning profile for iOS
The database model
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.
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:
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 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.
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:
|
Method |
Advantage |
Disadvantage |
|---|---|---|
|
Offline |
Locally stored App can be used out of network coverage |
File can be corrupted Not portable between devices |
|
Online |
Permanently available Unlikely to become corrupted by app failure Can be used by any device |
Requires connection (updates may therefore not always be in sync) |
|
Both |
Portable App can be used when not in network range Unlikely to be corrupted Can be used on any device |
Synchronization |
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.
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:
"Common.Save"="Save";
Android: This is more in line with a standard XML format, as shown in the following code:
<string name="Common.Save">Save</string>
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.
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.
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
A unique identifier
Who it is from (a contact)
Date and time sent
Attachments (though this will be from a separate table, linked by ID)
The previous message Id
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.
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.
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.
We now have to create a profile for our application. On the developer portal, select Identifiers.
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.
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
.p12file 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.
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.
We've covered quite a lot of information in this chapter, from enabling push notifications to registering your app with Google and Apple, and by now you should have at least an appreciation for what is involved in even the simplest of applications.
In the next chapter, we will start looking at the user interface and at using Xamarin forms for the application UI.
