I’m sure a lot of you are aware of or even attended Google I/O earlier this month. In Liverpool, we hosted an I/O extended event to live stream the keynote, and it was great to see so many local developers and enthusiasts turn up to watch it with us, even with Liverpool playing in the Champions League that night!

A common topic at the conference was of course Firebase. With 14 different talks concerning it, it’s safe to say there was a variety of new features to learn about. I’ve spent the last few weeks catching up with these talks, and I thought I would share what I’ve found.

What’s New in Firebase

An obvious choice, but a good one. This talk highlights all the new and sparkly features Firebase is bringing to us developers in 2019.

This talk combines live demos, case studies, and code examples, and is a great way to quickly understand what to try out next, and how they might help you as a developer.

A particular highlight for me is AutoML. I’ve always found Firebase ML really interesting but felt it inaccessible as I have no idea how to start without a pre-populated data set. It’s really exciting to see Firebase come up with ways to make Machine Learning even more accessible, and opens up the possibilities for everyone to make the most of it in their apps.

Zero to App: Live Coding a Cross-Platform App on Firebase

As an iOS and Android developer, I’m always a bit of a sucker for any sessions that focus on cross-platform development. I love being able to see features side by side on both platforms, and it’s a really good way of bringing mobile developers closer together.

I particularly enjoyed the style of this session, as it was all about collaboration and communication, while also showcasing the best features of Firebase.

ML Kit: Machine Learning for Mobile with Firebase

After watching the session focusing on new features on Firebase, and seeing the updates to MLKit, this ‘ML for Mobile’ session was of particular interest.

The way this presentation was mixed with live demos and code samples was really interesting and is a very engaging talk.

Some particular highlights for me were the offline language processing, which was shown to be incredibly fast for translations, and also the collaboration with IKEA, which lets you find matching or similar items in the IKEA catalogue.

As someone with a creative background, the collaboration with the Material Design team was really exciting. Sometimes more technical features can ignore the user experience for developers, and it’s fantastic to see this being thought about, while also making it easier to make beautiful apps while utilising MLKit.

Finally, the introduction of custom models is what had initially attracted my attention from the main session. I particularly loved the example of identifying dog breeds!

The user interface for the AutoML tab, which guides you through creating your own data sets, has really helped me understand more about the data and model that I want, whilst also taking away a lot of the complexity that has blocked me from approaching machine learning in the past. Being able to pick and choose between different sizes and training times makes it feel far more flexible.

Overall this is probably my favourite talk. I found the presenters were all really clear, and the live demos really helped me understand how I might use these new machine learning features myself.

Understand and Engage Your Top Users with Dynamic Audiences

Analytics is something that as an app developer, is really important to understand and utilise to the maximum of their potential. Having overall project level analytics is incredibly useful, and as a cross-platform developer, it is invaluable.

Enhanced filters

This new feature adds a huge amount of flexibility to understand the data provided by Analytics. The example they gave was whether completing the tutorial in a game meant that you stayed playing the game for longer and gave you better scores. Being able to apply these filters across platforms enables you to understand overall trends that might be less platform specific.

Being able to utilise Audiences to compare and contrast the data between different groups allows you to really quickly understand any differences. The removal of limitations on what and how many filters you can apply means that you can dive incredibly deeply into your data, which can only help you improve your own apps.

The particular highlight of this is the ability to make Audiences based on “Observed Behaviour”, which you can then use to target these users using Cloud Messaging, Remote Config and Google Ads. This means you can potentially address any issues or user behaviours immediately without requiring a new app build.

Furthermore, the Audience Builder interface is fantastically easy to use and is really clear on what data you will be collecting and what events you want to target by including the Summary card that gives visual guides for your data sets. I also loved the recommended analytics events that Firebase thinks you should use depending on your app’s category.

Analysis

The announcement of the new feature “Analysis” was really exciting to me. This is accessible through the Analytics dashboard once you’ve linked to Firebase. This gives you incredibly detailed access to your data, including visualisations such as Exploration, Segment Overlap and most interestingly for me, Funnel Analysis.

The ease of getting started with this immediately from Google Analytics is brilliant, and the UI is immediately easy to understand, which is something I’ve found difficult in the past with data platforms. The visualisation of creating a funnel completely makes sense, and you can get previews of how your data might look, and get immediate feedback on your app with barely any setup. The ability to “View Abandonments” is particularly interesting. It allows you to understand deeply your users who drop out of your defined funnels, which could prove incredibly valuable!

The period comparison feature within the scatter plot graph was really interesting, and it is so easy to understand the trends in your data and identify and declines before they become serious problems. You can then link this in to the Audiences features to target any issue groups, giving you huge control over your app and your users.

Analysis rolls out this Summer.

I’ve only scratched the surface in this post on the range of topics and things to learn about Firebase from I/O. I’d really recommend watching the talks I’ve highlighted above, and you can find the Firebase at I/O playlist here for the rest.

This is the third part of the ‘Getting started with Firebase on iOS’ series. We are currently part way through creating an iOS app that mimics the functionality of the Slack app, LunchTrain. You can find the second part here.

In the second part, we covered implementing the Train Detail screen, and also did some refactoring. In this part, we will implement notifications and Cloud Functions. Note, you will need an Apple Developer Account to do this section. It will not be vital to finishing the app.

We will follow this by implementing some database rules to better control what a user can do and see in the app, including not locking the user out of certain functionality by not being able to log in.

Notifications

Remember, in order to complete this section, you’ll need a paid Apple Developer Account and a physical iOS device. Unfortunately this doesn’t work on the simulator ☹️

To get your account ready and set up your app, you’ll need to first log into the Apple Developer Console. Once there, navigate to the Certificates, Identifiers and Profiles section, and then the Identifiers -> App IDs section, and click the + button to start adding a new ID.

We now need to fill out the following:

• App ID Description — Just your app’s name.
• Explicit App ID — This is the id you have in your project file. For example com.yourname.lunchtrain. You should already have this from linking your app to Firebase.

Then under App Services, tick `Push Notifications.` Press continue.

Now confirm the details you entered are correct, and press Register.

Now we want to edit the details of the App ID you just created, so select this, and click the Edit button. Scroll down to the Push Notifications section, and select Create Certificate.

The console will then guide you through generating this certificate. Follow this through and download the final result.

Now you have the certificate, find it in the Finder, and double click to add it to your keychain. Next, open up Keychain Access application, and find the certificate. It should be under the My Certificates category.

Once you have found it, click the arrow on the left to expand it, and right click on the private key and select Export and save it to a convenient location.

We’re now done with all the developer console faff! yay! Now we can move back to the Firebase Console to get the set up completed 😅

Go to the project settings for your app in the Firebase Console. Select the Cloud Messaging tab at the top, and scroll down to the iOS App Configuration section. Click the upload certificate button in the Development section, and navigate and upload the certificate we saved in a convenient location earlier.

Remember, if you want to release your app in the App Store, you will need to create a production certificate and set up the console accordingly. In this tutorial, we are going to stick to the development setup.

Now all the config is complete, we can move back to writing some code and getting it running on a device! 🚀

Another pod! This time, we want the Messaging CocoaPod, like so:

pod 'Firebase/Messaging'

Now head over to the project file, and navigate to your target, and select the Capabilities tab. In this menu, turn on the Push Notifications switch.

Now we want to update the AppDelegate. Implement the below changes:

Now we’re all set! Run the app to get your device registered and ensure that everything builds properly. We can now send a test notification to check it all works.

From the Firebase console, navigate to the Cloud Messaging section, and select the option to Send your first message. Fill out all the relevant details, and hit send! Your test notification should now appear on the device you ran the app on. Remember, this only works on real devices, not the simulator.

Cloud Functions ☁️

Now we have push notifications set up, we want to work out when we want to send these notifications. We can do this using Firebase’s Cloud Functions. These are basically small snippets of Node.JS code that sit on a server and can be triggered by a variety of conditions. Handily, one of these conditions can be when data changes in the Firestore!

We need to get the environment set up first though, which requires us having the Node package manager installed on your terminal. This is a great guide for installing Node.js and the package manager using Homebrew: https://changelog.com/posts/install-node-js-with-homebrew-on-os-x

Once you’ve done this, navigate your terminal to your app folder, and run the command:

npm install -g firebase-tools

This installs all the available tools to use Firebase on the terminal globally, so you can access from any folder.

Next, run firebase login and sign in to the account you have your app registered under.

Now you can run firebase init functions and follow the guide that is provided. Once this is set up you should find that a functions folder has been created in the directory, and a firebase.json file. Open up the index.js file from the functions folder in an editor of your choice.

First, add this code to the top of the file:

// The Cloud Functions for Firebase SDK to create Cloud Functions and setup triggers.

const functions = require('firebase-functions');

// The Firebase Admin SDK to access the Firebase Realtime Database.

const admin = require('firebase-admin');

admin.initializeApp();

You should find an example function ready commented out. Uncomment this, save the file, and then run the command:

firebase deploy --only functions

Once this has completed successfully, you should be able to see your function in the Cloud Functions section of the Firebase Console.

Triggering Functions

Now we have Cloud Functions all set up and our environment ready, we can start creating the function that will observe our Firestore.

The below function simply watches for any new trains being created. Currently it doesn’t do anything when this happens, it just gets the name value from the new Train. However, we can use this to test that our set up is working.

exports.newTrain = functions.firestore.document('trains/{title}').onCreate((snap, context) => {

const newValue = snap.data;

const name = newValue.name.toString();

});

Once you’ve added this function to your index.js file, run your app and test out adding a new Train. You should be able to see in the Firebase Console the latest call of the function.

We’re getting an error here as we haven’t actually returned anything in our function, however we can see that the event has linked up correctly! 🙌🏻 You’ll also notice an error due to not adding a billing account — this is fine for now in development, but will be needed to be added should you start sending more requests.

Now we actually want to handle this event, and send off our notification when this happens.

Sending our notification

When we start to think about being able to send notifications to registered devices, we come across a bit of a problem: We don’t know the devices registered! One solution to this is to subscribe each device to a Topic. We can then send notifications to any device subscribed, rather than having to get a list of devices from Firebase. This also makes it much easier if we ever want to implement a settings page where users can subscribe and unsubscribe to certain notifications.

This is the best solution for when a new train is created, if we want to send a notification to a train owner when someone joins for example, a directed notification to their device token would be more suitable, and when sending a notification about the train leaving, device group messaging would be best. Handily, we have a use case for the three different types, so we will cover all of these in this section.

Topic Messaging

In order to create a topic for devices to subscribe to, we simply need to call the subscribe function and the server will create the topic automatically if it doesn’t already exist.

In the AppDelegate within the didReceiveRegistrationToken method, add the code:

func messaging(_ messaging: Messaging, didReceiveRegistrationToken fcmToken: String) {

...
  Messaging.messaging().subscribe(toTopic: "newTrains")
}

Now run the app, and the topic newTrains will have been created, and we can use it within our function.

Add the extra code to the newTrain function, which creates the payload and options for the notification, and handles sending this to the newTrains topic.

Make sure to deploy the new index.js file!

Now we can test that this works by creating a new train from our device, and see whether we receive a notification. We should also see it logged out in the console as before, and see the relevant notification sent in the Firebase Messaging section.

New Passengers

Here we want to do some refactoring to actually link users to a train, and to do this we actually need to store our Users when they sign up. To do this we want to make the model in our code, and start linking up.

struct User: Codable {
  var userId: String?
  var userName: String
  var deviceToken: String? = ""
}

You’ll notice we’ve now got this Codable within the struct declaration, this allows us to skip the pesky dictionary declaration.

In order to use this with the Firestore, we can use this great library, called Codable Firebase

alickbass/CodableFirebase

Then when we want to encode a new User to send to our Firestore, we can simply call this:

let newUser = try! FirestoreEncoder().encode(User(userId: userId, userName: userName, deviceToken: deviceToken))

...

transaction.setData(newUser, forDocument: newUserReference)

And the same for decoding the data when we receive it:

do {
  let model = try FirestoreDecoder().decode(User.self, from: document.data())
  return model
} catch {
  print("error parsing document: \(document.data())")
  return nil
}

Now we want to be able to set up the user when they sign in, store their details along with their device token that gets set when they register for notifications. Handily, only once a user gives permission will we have this value, so we won’t be wasting time sending notifications to people who said no anyway!

First, we want to get the device token. We can do this by adding this method to the AppDelegate:

func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data)  {
  if let refreshedToken = InstanceID.instanceID().token() {
    let defaults = UserDefaults.standard
    defaults.set(refreshedToken, forKey: Keys.deviceToken.rawValue)
  }
}

Here we’re just saving the device token to the UserDefaults, ready to use later once the user has signed in.

Then, in our BaseViewController, we can add the call to get this device token, and save our new user:

func authUI(_ authUI: FUIAuth, didSignInWith authDataResult: AuthDataResult?, error: Error?) {
  let deviceToken = UserDefaults.standard.string(forKey: Keys.deviceToken.rawValue)

TrainService().saveNewUser(deviceToken: deviceToken, callback: nil)

showList()

}

Notice we have the device token as optional in both the User object, and the saveNewUser function.

Now we have our Users, we can attach a user id to the passenger collection, which then allows us to have a reference to everyone interested, and send notifications to a set of devices.

In the next part, we will dig into the Database Rules we can use with the Firestore, and implement proper grouping and privacy for our trains.

For now, though, this post is going to focus on what you need to do to migrate your Crashlytics instance across from Fabric to Firebase.

I’m going to be using one of my more basic projects on GitHub to run this through, so feel free to post any questions if I miss anything that might be the case in more complex projects.

First off, if you use Fabric often, you’ll probably have noticed this header pop up in your dashboard. If you click on the Get Started button, you’ll be redirected to a handy migration assistant.

Now you might be asking, why make this blog post if Firebase has already made an assistant? Good question, but the aim of this post is to show you how easy it is to migrate even large repositories, and that it’s something you should be doing now rather than just before the upcoming deadline.

First off, you’ll be prompted to log in with your Google account. If it’s a personal project you can use your normal one, however, if you’re doing this for your company’s app it’s worth checking to see what your Android team-mates use for Firebase, or if there is a general Google account you can use for this.

Link your apps to Firebase

Before we can even start using Crashlytics within Firebase, we need to actually create the app in the Firebase console.

Once you click through to link your app, you’ll be greeted by a super handy dashboard.

Then you simply need to drag the app you want to link, over to the box on the right:

You’ll then be given a dialog where you can fill out the relevant information for your new Firebase app. You are then given the choice of whether to share your anonymous data with Google, of course, your choice!

You’ll then see a big button across the bottom of your screen to complete the link between the apps. If you logged into the Firebase console you would now see the app you just created, however it won’t have the link yet.

Hit that button, and confirm. You can now invite your team mates to your new Firebase app, and directly go to your new console and see what you’ve got set up already!

Now when you go back to the migration page, you’ll see your new Firebase app.

Adding Crashlytics

Now we have our new Firebase app set up, we can start to link up Crashlytics too.

To do this, you’ll want to head over to your app’s Firebase console. Once there, you’ll notice a little red dot over your new app, this is prompting you to finish the SDK set up so we can start using the full feature set of Firebase.

When you continue through this, all the app details such as the Bundle ID, are already populated from Fabric. Now we have to download the GoogleService-Info.plist file and add it to our project.

Next, you’ll want to add the Firebase/Core pod to your Podfile :

pod 'Firebase/Core'

Save the file and run:

pod install

Now we can add the initialisation code to our AppDelegate. This works in a similar way to the Crashlytics set up:

import UIKit
import Firebase

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

  var window: UIWindow?

  func application(_ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?)
    -> Bool {
    FirebaseApp.configure()
    return true
  }
}

Now run your app, and it should link up with Firebase automatically.

And that’s it! You’re up and running with Firebase, and Crashlytics should have automatically been turned on.

Head to the Quality section, and hit Crashlytics. You should reach a dashboard giving you all the information you need

Have fun exploring all the features on offer from Firebase, and feel free to message me should you have any questions.

This is the second part of the ‘Getting started with Firebase on iOS’ series. We are currently part way through creating an iOS app that mimics the functionality of the Slack app, LunchTrain. You can find the first part here.

In the first part, we covered authentication and basic Firestore setup. In this part, we will first start with some refactoring and testing of the existing codebase. Then we will implement the Train Details screen, with the ability to see passengers, and also join a train yourself!

Refactoring

Currently, we have used a fairly basic MVVM architecture. This works well for this small scale project, though we have some points to improve.

Firstly, the table view in the train list access the view data, within the view model. This could be greatly improved by separating off the table view delegate methods into their own adapter class, allowing for as much business logic as possible to be outside of the View Controller.

Furthermore, given we are likely to use table views in other areas of the app, such as the passenger list, it is worth us using generics to design a adapter that can be reused.

This is the one we will use in the lunch train app. You can build on this to provide more of the delegate methods, depending on your requirements, but for now this implementation is enough for us.

In order to use this in the app, we need to adjust the view controller as below:

Again, the block within the didSelectItem section doesn’t need to be implemented yet. We will be covering that in the next section. I will do other small refactors as we go 😊

Create a Train

Now we’re going to move onto adding new Trains from the app. For this, we will need to use some different methods for the Firestore, and implement a new UI.

We will start with the UI and structure first.

Create a NewTrain folder, and add theNewTrainViewController.swift and NewTrainViewModel.swift files. We don’t need view data here as we can just reuse the Train model.

You will note that I have added an option to handle an error when creating a new train. We will be looking at error cases and adding UI for these in a later post! For now, to the user, it will not crash but simply dismiss the screen:

Next, we want to hook this up to the button we have in the list view. This is fairly simple:

@objc func addPressed(sender:UITapGestureRecognizer) {

    performSegue(withIdentifier: "addTrain", sender: self)

}

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {

    super.prepare(for: segue, sender: sender)

    guard let viewController = segue.destination as?   NewTrainViewController else { return }

    viewController.viewModel = NewTrainViewModel()

}

As you can see, we now have a dedicated screen for entering the train details, which automatically gets the user’s name and creates a new Train. If you open the Firebase console while creating this, you should see the collection automatically update, and the list will update with the new Train when you return to it.

Viewing Trains

Now we want the user to be able to select a train, and see the relevant details. For this again, create a new group, named TrainDetails and add the files TrainDetailsViewController.swift TrainDetailsViewModel.swift and TrainDetailsViewData.swift

In the view data, we will have a reference to the Train and also the DocumentReference for the chosen train, in order to perform operations later.

Then in the view model for now, it will only contain the didChangeData block, as we don’t need to do any network calls or data manipulation for now.

Again, feel free to customise your UI as you see fit. I have included a table view and a button ready for the passenger list and the ability to join a train.

So at this point, we have the ability to see the trains, and click into them to view more details. The join train button doesn’t currently work, so the passengers list isn’t functional at this point.

In order to implement this list, and the button, we want to add similar functionality to how we handled the list of trains, but just listen to a different collection of documents.

First off, we want to create a new data class to represent a user. This is really similar to the Train model we made earlier.

For now, these users are going to be made per train. Later on we can look at improving this, so a user can see all the trains they have joined, and manage their trains more effectively.

Add the methods to the TrainDetailViewModel as shown below, to observe the passengers collection within the Train model.

Next, just add the viewModel calls into the view lifecycle methods, to ensure no observers are left over when you leave the screen.

override func viewWillAppear(_ animated: Bool) {

  super.viewWillAppear(animated)

  viewModel.observeQuery()

}

override func viewWillDisappear(_ animated: Bool) {

  super.viewWillDisappear(animated)

  viewModel.stopObserving()

}

deinit {

  viewModel.stopObserving()

}

Now you should be able to run the app, but nothing will happen! This is because there’s not actually any data in your passengers collection yet, and there probably won’t be that value in the database either! So first we need to initialise each train with the list of passengers with just the owner inside.

Head over to your Firebase console, and delete all the trains you have in their, or add a passengers field to each, otherwise we’re going to have issues later! Our guard statements keep us pretty safe, but in order to keep our database clean it’s a good idea to reset here, while we’re in active development.

If you choose to add to existing Trains, make sure you click Add Collection rather than the Add Field, as this then creates a new collection inside the train document. Your console should then look similar to below:

Last, but definitely not least, we want to give our table view the data we get! Again, we’ll do this in the same way as in the list, with a table view adapter to handle the data. Handily, we made a generic adapter in our first part, so we can simply reuse this! Just make the below changes to the TrainDetailViewController :

You’ll note that we have made a cell view this time, for now this is fine, as we only have the name field to show. We will customise this more in future parts 🎉

Now when you load up your app, if you’ve added a train with passengers, you should be able to click on this and see the list in the detail view.

If you haven’t yet, try adding some data into your trains, and see what happens. Does the app crash if the data isn’t the right type?

Joining a Train

The last main functionality we’re going to add in this part is the ability for a user to join a train. For this, we want to add a gesture recogniser to our button, and handle the tap. When this happens, we want to get the user’s name, and simply create a User, which can then be added to the passengers collection. This should then automatically update the table view in the details.

In terms of UX, we probably want to add an activity indicator to replace the button whilst this is handled. And also the option to grey out the button if the user is already in the train. We’ll be adding the ability to leave a train later (again 🙃)!

First, add this code to our setup method:

let gesture = UITapGestureRecognizer(target: self, action: #selector(self.joinPressed))

joinTrainButtonView.addGestureRecognizer(gesture)

Then we want to create the joinPressed method:

@objc func joinPressed(sender: UITapGestureRecognizer) {

  //call a method on the view model!

}

Now this is all tied up, we can implement the method on the viewModel. Add a public method joinTrain as below:

fileprivate func baseQuery() -> CollectionReference? {

  return trainReference?.collection("passengers")

}

func joinTrain() {

  guard let query = query else { return }

  let user = Auth.auth().currentUser

  let name = user?.displayName ?? ""

  let passenger = User(name: name)

  let newPassengerReference = query.document()

  Firestore.firestore().runTransaction( { (transaction, errorPointer) -> Any in

    transaction.setData(passenger.dictionary, forDocument: newPassengerReference)

}) { [weak self] (object, error) in

  guard let strongSelf = self else { return }

  if let error = error {

    print(error)

    strongSelf.joinTrainRequestCompleted?(false)

    return

  }

    strongSelf.joinTrainRequestCompleted?(true)
  }

}

You’ll note I’ve change the baseQuery method to return a CollectionReference to allow use to more easily create new documents. You’ll need to change the baseQuery type to CollectionReference too.

You’ll also notice that I’ve added a new callback, joinTrainRequestCompleted . We can use this to handle stopping the activity indicator, and display an error if needed.

In your bindViewModel method, add this:

Once you implement the new code for the detail view controller, you should get a similar result as the GIF on the left. Feel free to customise this as you wish.

You’ll notice that once we’ve joined a train, leave the view, and then return, the join train button is available again. In order to handle this, we need to cross check the list of passengers against the current user. Again, this will be simpler once we know which lunches a person is involved with, but for now this will work.

Add the following code to your view model. Here we are getting the current user’s name, and doing a simple check within the passengers list.

private func checkIfUserIsAPassenger() {

  viewData.isUserAPassenger =   viewData.passengers.contains(User(name: getCurrentUserName()))

}

private func getCurrentUserName() -> String {

  let user = Auth.auth().currentUser

  return user?.displayName ?? "" 

}

Add a isUserAPassenger boolean field defaulting to false on the TripDetailViewData struct. This allows us to simply check this value in the view controller, rather than having more complex callbacks or logic to deal with.

You’ll notice at this point that we will have build errors. This is because the compiler doesn’t know how to compare different User objects. For this, we need to make User conform to the Equatable protocol.

Add this extension to your struct:

extension User: Equatable {

  static func ==(lhs: User, rhs: User) -> Bool {

    return lhs.name == rhs.name

  }

}

Finally, we want to trigger this check. It makes the most sense to check this any time the data is updated, so within the didSet of the viewData.

var viewData: TrainDetailViewData {

didSet {
    checkIfUserIsAPassenger()

  }

}

Because we want to update the view data after this check, we can move the didChangeData?(viewData) call to within the check method. Simply add the call to the checkUserIsPassenger() function.

Now we want to handle this. Within the didChangeData block in the TrainDetailViewController , add the code to grey out the button if the value is true.

if data.isUserAPassenger {

  strongSelf.disableButton()

}

The disableButton method contains the code we wrote earlier:

private func disableButton() {

  joinTrainButtonView.backgroundColor = UIColor.gray

  joinTrainButtonView.isUserInteractionEnabled = false

}

Now we just need to call the check in the viewModel! Just add the function call within the response from the firestore, as shown:

self.viewData.passengers = models

self.checkIfUserIsAPassenger()

self.documents = snapshot.documents

This means anytime the data is updated, we will be checking the value. There are likely more efficient ways of doing this. Can you think of any? Perhaps within the mapping of the response from Firebase?

Now we have the main functionality of the app in place, we are in a good position to start implementing more than the MVP. In the next part, we will go through how to implement notifications, and for a user to be able to manage the trains they’ve joined. We ill also look into some database rules, to ensure that a user can’t join a train twice, for example.

Let me know any questions you may have in the comments, and as always feel free to ping me on Twitter!

In this blog post series, I’m going to take us through making a full iOS application, using Firebase. We’ll be making a Lunch Train app, which mimics the functionality of the Slack application. This tutorial is aimed at those fairly new to iOS development, and having never used Firebase before. However I would hope those who are experienced in either can find this useful.

The main features are:

• A user can create a “Lunch Train”, choosing a place and a time
• A user can join a “Lunch Train”
• A user can see the passengers of the “Lunch Train”
• A user can be notified when people join their train
• A user can be notified when the train is leaving

Throughout this post, I will be using the term “train” to refer to a “Lunch Train”.

In this part, we will get the user authenticated, and setup the Cloud Firestore to have references to different trains.

Set up Firebase

Go to the Firebase console, and log in with your Google account. You should be presented with the Firebase welcome screen, click the ‘Add Project’ button.

Fill in the relevant details for your app, this can be anything as you can edit it later. Once the setup is complete, you will be in the Firebase console.

Select the ‘Add Firebase to your iOS app’ button. This is the step where we now want to know a couple of details from our application. Switch over to Xcode.

Create a new single view app in Xcode, with any name you want. The organisation name and identifier form the first part of the bundle ID, and this value is what you will be entering into the Firebase console.

You should now be presented with the project information screen, take a copy of the ‘Bundle Identifier’. Now go back to your Firebase console, and enter it into the first field of the dialog.

Next up, Firebase will provide a GoogleService-Info.plist for you to download. Follow the instructions here and insert it into your project.

Firebase Cocoapod

Firebase is provided as a CocoaPod — make sure you have this installed before progressing to the next step.

From the terminal, navigate to where you have created your project, and initialise the pod spec.

cd Documents/Firebase\ Project

pod init

Now open the Podfile. You can do this by simply running open Podfile from the terminal.

# Uncomment the next line to define a global platform for your project
# platform :ios, ‘9.0’

target ‘Firebase Project’ do
# Comment the next line if you’re not using Swift and don’t want to use dynamic frameworks
use_frameworks!

# Pods for Firebase Project

target ‘Firebase ProjectTests’ do
inherit! :search_paths
# Pods for testing
end

end

Add the line:

pod Firebase/Core

Make sure you save! Then back in the terminal, run pod install. This will go through your Podfile and install any missing dependencies. Once this is complete, close Xcode, and open the newly generated .xcworkspace file. You should see the Pods project within the Xcode project navigator now.

Click to the next step in the Firebase dialog, and the code provided to insert into the AppDelegate is provided. Simply import the Pod, and add the configure line.

Once this is complete, when you run the app, it will link up to your Firebase account. You should be able to see the active users value is now at one under the Analytics option.

Authentication

Now we have our app linked to Firebase and our project, we can start the development of our Lunch Train app. We will want a way of identifying users, and for users to be able to have trains associated to them, therefore having a form of authentication makes sense.

Luckily for us, Firebase provides a platform for this. In the console, select “Authentication” in the sidebar menu.

We then want to set up some sign in methods. Firebase offers a range of options for this. However for this project we will just stick to Google & email sign ins for simplicity. Simply click through on the Set up sign up method and enable to two options.

Add Authentication to the app

In order to use Firebase authentication, we can use the pre-made authentication flow, which provides some basic UI and handles the calls for us.

We’ll need two more pods for this:

pod ‘FirebaseUI/Auth'

pod 'FirebaseUI/Google'

Then we want to import these into our ViewController.swift class:

import FirebaseAuthUI

import FirebaseGoogleAuthUI

This allows us to then launch the authentication on start up. Add the viewDidAppear override method to your code, and show the authentication flow if needed:

We also need our ViewController to conform to the Auth delegate.

class ViewController: UIViewController, FUIAuthDelegate {

and then implement the auth UI method:

func authUI(_ authUI: FUIAuth, didSignInWith user: User?, error: Error?) {

  // Handle user returning from authenticating
}

Once you’ve signed in, you will be able to open the Firebase console, and see that user account in the authentication section.

Showing some data

Now we have users and a way to authenticate them, we can start to use the Cloud Firestore. Navigate to the database section in the console, and enable the Cloud Firestore. We will start off in “Test Mode”, which allows reading and writing data without authentication. We will dig more into database rules in a future post.

Create a trains collection, and add a few test documents. Select auto-ID and create the owner place time and title fields. Make sure the time field is a timestamp type, all the rest can be string .

Now we have a sample set of data set up, we want to be able to view this in the app. First, add the Firestore pod to the project:

pod 'Firebase/Firestore'

Create a TrainList group within the project, and create the classesTrainListViewController.swift TrainListViewModel.swift and TrainListViewData.swift

We’ll start at the data layer. We want to create a Train data model to map from the data from the Firestore, and we want a way to reference the list of trains shown in the app.

Now we want to use this data, in the view model layer, which is where our business logic for retrieving from the Firestore, and handling the data sits.

For initialising our view controllers with a view model, I used the technique detailed in this blog post https://medium.com/@shanev/view-model-specialized-view-controllers-using-storyboards-in-swift-88169d2b43c7

Finally, we want to create our view controller, with a table view to show the trains in the database:

You can customise how the cells are shown if you wish. With a basic implementation you should get something similar to the screenshot here.

I have also added a ‘Create Train’ button here, but this isn’t required yet, and I will cover this in more detail in the next post.

What you should notice now, is that if you have the app open, and add or delete items in your Firestore, it should be reflected in your app immediately, thanks to the listeners added in the view model.

To note, if there are parts that you wish to see more of and dig into the code, you can find the full repository here:

niamh-power/lunch-train

Note this is a more complete version than we have currently at this stage in the series, though you should still find everything you need.

In the next post, we will be looking at some refactoring that we can do to the current code, as well as adding the option to create a train, and join any existing ones. You can find that next post here!

Feel free to comment below or message me on Twitter if you have any questions or thoughts!

This is a re-blog of my post on the Novoda blog.

Last November, Novoda hosted their first annual ‘un-conference’ in Lisbon, Portugal. The idea of an un-conference is that potential speakers can submit a topic and attendees vote on what they want to hear about on the day. The three formats available were talk, workshop, or discussion. One of the key themes of the day that emerged was mental health in the workplace.

Burnout : physical or mental collapse caused by overwork or stress.

Before attending the unconference, I had been taking on more and more “extra-curricular” activities at work, and with deadlines approaching on my project, I was really struggling with stress. The resulting discussions that took place regarding mental health were fascinating, and really humbling to hear how many other people struggle with this in their day to day lives. It was also incredibly relieving to know that I wasn’t the only one having stress related issues, which aided me in finding a resolution.

Mental health is still a somewhat taboo subject and conversations like the ones we had at the unconference should happen more often. With this blogpost I hope to kick-start a discussion on workplace stress with the hope that it becomes a topic we can begin to approach with ease, both within and outside of Novoda.

Following the unconference, I made a particular effort to try and understand the steps I take to battle burnout, and I found there are three points to consider when approaching your own mental health. Get these right and you’re in a much stronger position to be able to jump any hurdles that come your way.

Communicate

If you can feel yourself getting burnt out or stressed my first piece of advice would be to talk to your employer. Initiating that first point of contact is a crucial first step and in my case, I was completely supported and only received offers of help.

This is only possible in certain companies however, so it depends on your circumstance. Having a healthy support network of friends and family that you trust to be able to talk to about any struggles you are having can be really beneficial and can help if talking at work is problematic. I often found just chatting about my day to day stresses very therapeutic, and ensured I didn’t overthink, or lose sleep, over potentially menial problems. Trying to get involved in more extra curricular activities outside of work can also help, as this gives fresh perspectives, and a broader friendship circle.

Switch off

Switching off and allowing yourself proper resting time is vital to maintaining a healthy work-life balance. I find one of the key techniques for allowing yourself to disconnect from work is to set a strict time from which you don’t touch your laptop. This is especially important if you work remotely, as it is far too easy to continue working in the night.

One technique I employ is to have separate work profiles on my machine which prevents any unwanted notifications after work time. Enabling ‘alarms only’ mode on my phone after work and before I start (6pm - 8am for me) every day has also been particularly helpful.

Furthermore, taking up a creative hobby such as painting has been incredibly beneficial to my personal mental health. I would advocate this to anyone struggling with burn-out.

In the past, I have also known a few people to take an extended break from the day-to-day grind of work. It doesn’t even need to be a holiday abroad, just a change of focus can really help “cleanse” your mind. The opportunity to do this is of course incredibly fortunate, and many don’t have this chance.

Prioritise your sleep

According to the Mental Health Foundation, a good amount of sleep is [vital to maintaining a healthy mind](link!). This is difficult if you have a large commute or other commitments so it is a case of balancing this carefully.

One key purchase can be a seasonal affective disorder lamp. This is a light you can set to gradually turn off in the evenings and turn on in the mornings. My personal experience is that this results in you waking up much more naturally and also aids in falling asleep if this is something you struggle with.

As part of this blogpost, I put out a call to other developers in the community for their experiences and advice on mental health and burn out. The response was fantastic. Thanks to all those who responded.

One of the key points of advice I found was to have a healthy life outside of work. Ensuring you exercise and eat well gives you a great foundation to work on your mental health. Taking value in your weekends is also imperative - getting away from home every now and then can do wonders for feeling cabin feverish and can help stop the temptation to work outside of working hours.

Within your working environment, reminding yourself that at the end of the day, your job is indeed just a job can help you put everything into perspective. Your mental wellbeing is your priority. If the culture is toxic or you’re feeling undue pressure don’t be afraid to start looking at other options if you are able to.

Additionally, a common snagging point is when developers start moving to more of a senior role. Finding the balance between being more of a mentor / manager and writing code is really difficult, so it is really important to have clear communication with your manager as to what the expectations are. Don’t feel afraid to discuss possible improvements with more senior figures if you’re struggling with the work load or are unsure of the next step to take.

It takes time, but being able to separate issues at work so you aren’t staying up all night thinking about them is a really vital skill. There are always going to be difficulties, but it is more how you approach them and deal with them mentally that is important.

Getting a grasp on good time management can be really helpful too. By time boxing your work, you can give yourself more discipline and give realistic expectations to your colleagues. This of course needn’t apply to work only. Other issues that could be troubling you, like personal finances, can be addressed by setting aside some dedicated time for them. You will often find out that a brief but focused session can resolve concerns that have been looming over you for months.

In addition to this, creating a list each morning of everything you would like to achieve by the end of the day, and then being able to pick this up the next day can help you to visualise the scale of your work, which is often smaller than you might think. This also benefits your evenings, as less of your mental capacity is spent worrying about what you need to do tomorrow.

For employers, having a friendly and open HR department works wonders. Advocating for a culture of openness and support can ensure employees feel comfortable opening up when they’re struggling. At Novoda, we are planning on meeting fortnightly to discuss techniques on the best ways for the company to tackle any problems people may be facing.

In all of our offices, we have break-out areas with more relaxed seating, games consoles and an arcade machine. This helps to foster an environment that encourages people to take breaks from their work and relax.

By making it clear that mental health is as important as physical health, and that taking days off when everything’s a bit overwhelming really helps. When employees are encouraged to work late and there is little tolerance for taking time off, burn-out is the result, as well as deeply unhappy workers. This also can lead to a toxic culture that is far more competitive than healthy.

Take these steps, and you’ll be well on your way to creating a company culture that is inclusive and open and attracts a fantastic group of people.

Personally, I only recognised I was struggling after I heard of other’s experiences at the un-conference. This gave me the confidence to talk to those at work who could help, and it’s been great to have that line of communication open for whenever I need it.

My main point of advice if you are struggling with any mental health issue, would be to talk to someone close to you. Talking to someone you trust makes it real and allows you to start making a plan to tackle it head-on. I hope this blog has given you some confidence to take this step or to make the moves to avoid any problems in the future.

Finally, the points I’ve raised in this blog talk to those seeking ways to help general day to day stresses, which can ease the root causes of mental illnesses. This doesn’t apply to all, and sometimes counselling and / or medication can be the best way to help. If you aren’t sure, be sure to go and speak to your doctor, or a healthcare professional and they will be able to point you in the right direction. This page from the NHS in the UK provides some really helpful phone lines, that can offer more professional advice. For those outside of the UK, there are many charities that provide help and advice, and also some fantastic online resources, such as BetterHelp for more relevant advice.

It is particularly important to note that more than one approach could apply to each person, especially if they are experiencing various different symptoms. For example you might benefit from medical treatment but could also need to improve your lifestyle, exercise more, sleep more, or just build better habits. Don’t treat this as a chore (“I already did one thing, therefore I can ignore the remaining difficulties I’m facing”). Use every possible means of improving your life quality and you’ll be on your way to thrive!

Step 1 — Keywords

First off, if you’re debugging an error message, pull out any individual information, such as file paths. This allows you to search a wider range of results.

Step 2 — Source

Where is your error coming from? Is it a library? If so, look up the library’s GitHub page (if it has one), and check out the issues page. It’s likely someone has come to this error already and has had a response with a solution.

If it hasn’t already been raised and the solution isn’t clear, raise an issue yourself, giving the developers as much information as possible. Also try and get a second opinion on your error, check on another codebase or computer, just in case it’s an issue with your set up.

Step 3 — StackOverflow

Ah, the trusty StackOverflow, what would we do without it? I often find searching directly into StackOverflow brings up results otherwise hidden by Google.

Step 4 — Describe the issue

If the problem is due to certain circumstances, try and pick out the keywords from this setup in your search term, as in step 1.

Step 5 — Ask your colleagues!

If no online methods bear any fruit, ask the person sat next to you! If you’re remote, ask on your company’s slack channel, or whatever communication method you use. Furthermore, there are many Slack groups set up that specialise in certain languages, with often fantastic communities who are incredibly helpful.

Also, never feel afraid to ask for help. More often than not other developers are more than willing to help you out, and will have faced the same issues you are at some point.

Step 6 — Explain it to yourself

A popular method for developers is known as ‘rubber duck debugging’. This is where you explain the problem to a rubber duck on your desk. 9 times out of 10 you realise the solution to your problem halfway through explaining it!

Finally, if you have any tips of your own to share, do comment below!

International Women’s day: a day to celebrate the achievements of women around the world, but also to highlight the inequalities many still face. Unfortunately, the tech industry is still years behind in terms of representing the real proportion of women in the population. Women still make up a tiny amount of those working in STEM fields, and the digital sector is no different.

I graduated with a degree in Computer Science last year, and although I would say that the overall experience was fantastic, the approach to girls in the subject at times was not. I can remember a tutorial/workshop session with around 10 of us in a room with a female tutor, and the attitudes of the male students towards her was at times uncomfortable. Another time, a friend was singled out to be put in an extra support group for a particular module, for what appeared to be no reason other than because she was female. The expectation that we would not achieve as much as our male counterparts was rife, and it results in many women who study Computer Science not going into programming based jobs. That’s not to say however that it was all like this, many lecturers were incredibly encouraging, and there were schemes to try and get more women into the field going on at the University.

Shockingly, the proportion of women in computing is reducing. In the 70s, the number of women in the field was increasing, to a high of 37% enrolled in Computer Science courses in the US in 1984. After this point, that percentage has continued to decline, to less than 20% today. The reasoning behind this is largely because of advertising — all the personal computer advertisements from this point featured solely male figures, implying that this was not something for women to pursue as a career option, or even as a hobby. These issues are still around today, with gaming and an interest in technical fields seen as something more suited to men. Industry is fully aware of the power of advertising to influence behaviour and bring about change. It is in their interest, and everyone else’s, for them to turn these resources to this problem. And yet, not enough is being done.

Image source: http://blog.modernmechanix.com/two-bytes-are-better-than-one/

However, some improvements have been made. A few months ago I went to help at my Mum’s primary school to teach some basic coding skills, as it is now part of the national curriculum, and I was amazed at how quickly both the boys and girls picked it up. Local meet-ups in Manchester such as Ladies of Code provide a platform for female developers to get into the industry and have a friendly environment to learn in. Computer Science is also becoming much more common as a high school subject, though the supply of teachers is very poor. In short, there seems to be an acknowledgement of the issue but the response has been disjointed and at times tokenistic.

I believe the main root of the issue happens much earlier in life; as children, many girls believe they cannot do the same activities or subjects as their male classmates. Of course, these gender stereotypes do not only affect girls: whilst I was outnumbered in my Physics A-Level class, my Art group had only one male member. In this sense, it is reasonable to conclude that sexism on a recruitment panel is less arbitrary, and more a result of an assimilation of latent gender stereotypes that we as a society possess: girls can’t play with cars, and boys can’t be princesses.

Although I was only doing my A-levels 5 years ago, I didn’t consider or know much about Computer Science and programming at the time. With the rise of companies such as Google and Facebook, the tech industry is looking ‘cooler’ than ever, and more and more young people are seeing it as an option. Yet the number of women in my field is still woefully low. Personally, I have found this has neither been a detriment, nor an unfair advantage. When applying for my job at Code, there was never an indication that I was in any way different, and this has continued over the last few months of working here. I don’t feel in any way inferior, and that has given me a fantastic environment to learn and develop. For women such as myself, there is a great career to be had in the Computer Science industry and I am loving every minute of it. But I have always been determined to follow this path regardless of the stereotypical comments and attitudes that are inevitable in a male dominated environment. The challenge is to reach women who are interested in Computer Science but are more dissuaded by these issues.

The problem cannot be solved by simply dedicating a desk in the corner of an office to females. Although this is a positive step in raising the awareness of women in the industry, it is perhaps demeaning to the achievements of the individual and opens women up to assumptions that the decision to give them the job was simply in order to satisfy their female quota. We need to start from the assumption that half of the best talent in the population lies in the female population and we need to realise that the computer industry is shooting itself in the foot by not addressing this problem energetically. The absence of a coordinated, comprehensive and effective national strategy to address this issue is a complete mystery to me.

Kudos to Twitter and several other high profile companies for directly addressing this issue in the past year. However, I believe that it’ll take more than this to adequately tackle the issue. Grants, changes to the national curriculum and general raised awareness is encouraging. But there’s a long journey ahead. Hopefully, one day companies won’t need to declare the number of their female employees. Maybe if my children follow my career path, when they’re interviewed for jobs, they will be comfortable in the knowledge that they’re entering a blissfully level playing-field, completely devoid of gender stereotypes. I’m not holding my breath though.

Personally, I have always wanted to do computer animation — ever since watching Shrek as a kid and seeing one of the ‘making of’ documentaries. I’ve always loved drawing and tech and it seemed like the perfect combination. Unfortunately as I got older I was persuaded that this wasn’t the best career choice, either because ‘it’s too difficult to get into’, or ‘there isn’t any money in it’. Even ‘you’re too smart for that’. Computer Animation at Bournemouth required 3 B’s if I remember correctly at the time; I was predicted to get 3 A’s, which apparently made it below me. (This may be me being incredibly cynical, but it definitely felt like this at the time!)

So, I ended up choosing to study Physics at university at the age of 17. My intention was to do this and then somehow get involved with working on Physics engines for games etc. On results day however, I changed my mind last minute to choose Computer Science, which I felt would allow me to pursue potentially creative outlets more than Physics would.

I’m now working as an app developer in both iOS and Android, and I really do love my job; I get to work on the design and functionality of the apps, which is great. But at times I find myself wishing I had had the confidence to pursue what I wanted to do from 13. The stigma that creative subjects aren’t for those who happen to be good at exams needs to be tackled. I do accept that yes, there aren’t as many jobs in those sectors, and the pay may not be as good. Plus, I am now approaching a position where I could pursue animation as a hobby and potentially freelance in the future, but not all would have that opportunity, and none of us are getting any younger!

The idea that in order to have a successful life you have to have a well paid job at a successful company is incredibly damaging to creatives, and demeans the aspirations of what I imagine to be thousands of young adults.