This morning, as we went to record the video component for our project, we hit a disaster. When trying to load the application using expo, we crashed expo. We had never experienced this before, and were immediately confused to why this was happening. Upon inspection, we realized it was due to installing a deprecated dependency to our application, to allow for unit testing.

Following this, we decided to uninstall and then reinstall our node packages, and check our package.json file. After doing this, we were able to get it to run on android again, but the ios package still springs errors. A fix for this is ongoing.

Today we spent a good bit of time working on the Technical Spec. This is basically a detailed design document that reflects both the initial design of the app and the current design, including any major changes that came about after the initial system design. This document covers a range of things, from an overview of the system to diagrams of the systems architecture to any problems we had a how we fixed them and what we want to do with the app in the future, like adding new features to it.

It was really cool to put this document together because I don’t think we actually had realised how far we’d come and how much we have accomplished until we saw it all coming together with the technical spec. Considering all the setbacks we’ve faced with this, we have come a long way over the past few weeks, and pulling all this together today helped us realise that I think.

Using Expo to develop our application has come with a welcome side effect – it has built in accessibility features to allow for all users to use our app with ease. Building these into our code will allow users who use voiceOver on iOS and TalkBack on Android to use our application – providing labels, which work like alts in HTML. Accessibility hints are another feature that is built in to Expo which will allow us to set hints which expand on the label of a function – such as allowing users to know that the DCU C&S button will take them back to the homepage of the application.

As our application uses sensitive scopes – the google calendar of a specific user – our consent screen has to be verified by google so that we can use it. This process, according to google, may take up to several days. Hopefully it will be done as soon as possible so that our demonstration can accurately show what our application can do.

Alternatively, Orla has set up an ‘internal’ project, which will only allow DCU members to login to the application. Because of this, any testing will have to be done using our own accounts, but it will allow us to show off our application in a way which truly demonstrates all the features.

We put together the user manual for the app today which wasn’t too bad. The user manual is a step by step guide of how everything works and how to use the main components of the app in plain simple english. To be honest, it was a little more pernickety to put together than we first realised – it’s amazing how once you get used to doing something you don’t even have to think about it, but when you have to actually write down exactly what to do or exactly how something works, it can be near impossible!

We all know how irritating things can get when you’re unfamiliar with something and trying to get it to work to no avail, so we made sure that we documented everything as clearly and concisely as possible so any person who wants to use this app will be able to use it to the best of their abilities. This meant going through everything from signing in to signing out and everything in between, and very carefully making note of each and every step for everything you can do on the app. This was followed up by writing out all the steps and taking some screenshots to show some of the processes in action.

I think after doing this we both have a lot more appreciation for people who make user manuals as their job, a lot more work goes into them than we realised!

One of the cool things about working with the google calendar API is that it makes implementing the reminder feature that we wanted to add to the application a lot easier. This is because we can have the user add themselves as an attendee of the google event – which will automatically send them reminders.

This is done, in our case, by updating the event in question using a fetch call. Users press the “Remind Me!” button to ask to be reminded of the event. Then, the event id, and the details about the event are sent to the addAttendee function. This function builds the data, adding the user’s email address to the attendee form, and allows our users to get notifications.

Previously, we thought we were going to have to get access to each users calendar on their phone – which Expo does have components to do – but doing it this way allows users to see the events that they’ve opted in for in their google calendar also, to allow for planning with college activities in a more streamlined way.

Seeing as we’re working on a calendar application, it would make sense that the main feature of the application is the ability to add events to the calendar.

We’re working with google calendars, meaning anything that needs to be added to an event will have to be done with Calendar API. This will be done using ‘events.insert()’. This will allow us to pass a calendar ID – which will be the email address of the club or society that is adding the event – and an ‘event’, which will contain all of the details of the event.

Once added to a calendar, all users will be able to view the event that was added – both on the main calendar which is the default view of the application, and on the calendar of the club/society the event is organized by.

We’ve decicded to impliment this in Node.js.

We have come up with a fix – using React Native rather than Apache Cordova – or PhoneGap.

This means that we can develop both applications – both ios and android – in parallel. This will speed up our process.

Unfortunately, this goes against what we had stated in our functional spec – however, we feel that this makes more sense for our application. We are excited to learn something new and develop with React Native.

Working with cross development applications has proven to be a challenge for us – Cordova setup was not going smoothly on either of our ends. Phoebe’s Mac installation had errors and bugs – attempting to run any builds produces a list of errors.

Orla’s Windows installation, on the other hand, has proven problematic, to say the least. Apache Cordova works using the SDK Platform for API level android-27. The main problem stemming from this is that the current SDK Platform for API level android-28. Cordova does not recognise android-28, and tracking down android-27 has proven to be difficult.

We are currently exploring other options, to ensure that we can develop the best version of our application possible.

In developing our application, we’ve come up with a wish list of features for our application.

• Adding Events to the Application
• Viewing all events
• Login
• Filtering Events – showing only ‘clubs’ or only ‘societies’
• Filtering Events – by time
• Add Reminder for an event
• Editing Events
• Deleting Events
• Adding favourite Clubs/Societies
• Featured/Random Event