Many of us have embraced ideas passed down from previous generations that promised to provide comfort and safety. In the last 10 years, we’ve seen how the disruption in our financial and social systems has affected those notions.
As part of my embracing of cross-platform, I’ve taken some time this weekend to port my iOS transit app, GWTA, from native iOS (Swift) to Flutter. My goal is to get a sense of the differences in the approaches using the simplest app I have.
I’ve included some breakdowns of the things that I did along with the approximate time it took to complete.
Project Management Tools (25 minutes)
Screenshots (what you’re building) – these were taken from the iOS Apps
Trello Board – I duplicated the stories (cards) in the iOS version and moved them into a separate list
Environment Setup (155 minutes)
Install iOS Simulator
Install Android Simulator
Install Visual Studio
Install Android Studio
flutter doctor – check that everything is installed correctly
had trouble locating the Flutter SDK but Android Studio downloaded and installed without issue, allowing it to be seen by Visual Studio
Having a later version of Cocoapods displays a warning in flutter doctor
for new project, I had to run sudo gem install cocoapods I wonder if I have to do this for every project
multiDexEnabled true in app/build.gradle
DON’T manually edit the Podfile. Flutter will handle it.
Where Do I Start?
After setting up the development environment, where should I start with the development process? I have a clear idea of the screens that I need as well as the data I want to display. I decided to take a top down approach and start with the bus routes themselves. I’m going to scaffold out the main screens of the app and fill in the UI as I go.
Route Stop Detail
The first fork in the road was after finishing the basic tooling and app setup, I could display sample data but I wouldn’t get much further without the actual bus route stop information. I had a choice of building out the UI with small sample data sets or setting up the actual route data on the backend. Gravitation towards my backend dev tendencies and to ease my earlier tooling frustrations, I opted for the latter. I knew I would have to eat the Cloud Firestore frog eventually and was hoarse from yelling at VS Code/ Android Studio and I wanted to move forward.
Backend (210 Minutes)
The iOS version has a static list of data. I’d like to move that route data into Firebase to make it accessible to both platforms and update when necessary. In reality, the route information doesn’t change very often but having it located here will prevent me from having to release a new version of the app when/if it does.
Setup/Install Cloud FireStore (25 Minutes)
I’m tempted to start with the Firebase (Cloud FireStore) implementation and have the app download the route and stop information but I’ve had so many bad hackathon experiences starting with the data that I’m a little gun shy.
Create FireStore Models (75 minutes)
One of the challenges I had in the previous version was that some stops are on multiple routes (e.g. The Transfer Center) so I duplicated the stop data for each route. It would be nice if I could represent that a stop was in on multiple routes using the colors, similar to what I’ve seen on transit systems around the world.
Create Routes in Firestore
Create Route Stops in Firestore
ETLProcess for Stops( 145 minutes)
Extracting stop data from native iOS app => spreadsheet and converting to JSON to import into Cloud Firestore
Ironically, I don’t have much front-end progress to show after 8 hours but the route data is loading from Cloud Firestore and I have successfully imported the stop data multiple times (testing the ETL process). I’ll chalk it up to beginner’s luck. I expect better from the next 8 hours with the focus on UI/UX. I’m certain there’ll be a few more headaches and roadblocks as I learn more.
Next 8 hours
Add Map UI
One of my bigger disappointments with the existing iOS app is that it doesn’t make great use of maps. I’d like to show users the closest stops to their current location along with the next arrival time.
Cloud Firestore Functions
The ETL process doesn’t create the needed geopoint type needed to represent each stop’s location on a map so I will add a trigger to create the field when a new document (stop) is created.
Add Schedule Info UI and Backend Data
The buses runs on different schedules on weekdays versus weekends and I want to display the next arrival time for each bus.
Add GWTA Information UI
These screens will probably remain simple webviews that link to the information on the GWTA website. I
In this episode, I talk about changes to the show and its release schedule, how I use music to set the mood while working and making the choice between tackling huge tasks versus small ones to start the day.
You can listen to the Cocoa Nomad Podcast on the following services:
In this episode, I explain why I stopped the Vegan Challenge after 18 days and explore the one of the primary reasons why people leave (or more accurately, why they should) and the pitfalls of labeling everything under the “quitting” label.
I’m excited to announce the launch of The Creative Nomad podcast, on which I was a guest. I had the opportunity to share my thoughts and work, travel and health with Jeff and it was a great conversation.
Don’t call it a comeback! In this week’s retrospective, I share the downsides experienced from intermittent fasting, its impact on my work and the June Challenge and surprise myself with July’s Challenge
In this week’s retrospective, I catch my breath after a long travel day (they let me back into the country!), learn that I’m not immune to accepting suboptimal solutions, set my sights on the June T-shirt Challenge and get ready for the announcements of WWDC.