Rambling while ambling
In the same way that a new business needs to have a strong handle on cash flow, a new remote worker has to develop a mastery over workflow. This includes time/attention management, effective communication and having an accountability/feedback structure.
I’m excited to be featured on Remote Working Hub!!! It was a great opportunity to talk about the importance of communication and accountability processes in distributed teams. #remotework #distributedteams #communication #accountability
“We may not be perfect.., but the safest hands are still our own”.
– Steve Rogers (Captain America: Civil War)
In this episode, I explore the question: “Are you doing what’s safe or what’s comfortable?” and how that question has impacted my choices of the past 4 years.
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.
In the latest retrospective, I rebound from illness, look to the future and face with the truth about what I should be doing in the last quarter of the year.
Show Links:
You can listen to the Cocoa Nomad Podcast on the following services:
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.
flutter doctorsudo gem install cocoapods I wonder if I have to do this for every projectmultiDexEnabled true in app/build.gradleAfter 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.
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.
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.
ETL Process 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.
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
After reading yet another piece on “Why We Switched To/From CrossPlatform/Native”, I decided that it was time to examine the state of cross platform app development for myself and not rely on the opinions of others, as their reasons for landing on their chosen solutions vary.
After watching the talks at this year’s Google I/O and Apple’s WWDC, it’s clear that the development puck in mobile is moving toward declarative UI with reactive state management. Much like Swift and AutoLayout, despite my initial feelings about these technologies, I’ve had to reconcile them against the reality of their increased presence. I believe that cross-platform development is no different. It’s simply a matter of the form that I find most palatable.
While my original intent was to build a SwiftUI app in time for the release of iOS 13 but I ran into too many issues early on to make that viable. However, these approaches are not mutually exclusive and maintaining development “purity” is far less important to me than putting solutions into people’s hands. Done is better than perfect after all. For now, I think a side-by-side comparison of the respective approaches of SwiftUI/Combine versus Flutter will provide enough some insight into where each each is in terms of maturity and utility. There may still be cases where the SwiftUI/Combine approach would make the most sense.
I’ve decided to proceed with a few of my existing iOS apps as a base to provide a point for comparison, each with escalating complexity.
A transit schedule app, for the Goldsboro-Wayne Transit Authority in Goldsboro, North Carolina, this is the simplest of my current apps. The goal here is to finally provide the long intended Android version to complement the iOS version that shipped in 2018. There are 3 screens of content that will provide a solid foundation using Flutter for:
I’m bringing my very first mobile app back from the grave. The current iteration is being built natively on iOS in Swift but I’d like if I can move faster with a cross-platform approach (factoring in the learning curve). The original version of the app was as simple as GWTA but the latest incarnation in more complex and will provide a nice testbed beyond the basics so that I can see what Flutter/Dart is capable of, specifically:
My expense tracking app for digital nomads will provide an opportunity to investigate state management in Flutter, as there are various screens throughout the app that are affected by changes to expenses. The newest version is almost ready to ship on iOS and getting a comparable Android version built will take some effort. On the positive side, I will be forced to ship smaller, more frequent updates in order to reach parity. From there, I will evaluate whether I should port the iOS version over to Flutter.
I have no idea where I’m going to land on the cross-platform vs. native debate but I imagine that like all things in development, the age old answer of “it depends” will still apply.
In this episode, I talk about the concept of arbitrage, share the ways in which I have used it and how you can make it work in your own life.
Show Links:
You can listen to the Cocoa Nomad Podcast on the following services:
I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram
Photo by Artem Beliaikin on Unsplash
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.
In this week’s retrospective, I turn a corner with the Capoeira Songs relaunch, debate a longer stay in Colombia and decide that it’s time for my first cosplay experience.
