You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought a GitHub issue could be a better way of leaving notes that wouldn't get lost in email or Slack. Also totally open to conversation here on it all.
So yea, I'm just gonna brain dump here with thoughts on what next steps for Android dev could be as I and after I transition off the team.
Onboard an internal dev
I think it'd be valuable to have at least one person on the team who could make Android changes and create builds if we're in a bind. I'm particularly thinking about scenarios where a crash is being reported from the app in production and all we'd need is something like a null check to fix it.
The goal would be to have a person whose dev environment is setup, can make code changes and can create builds for debug and release.
Near-term updates
This one's Matt's idea and I agree. I suggest we avoid doing any feature development for Android in the near future unless it's absolutely required. As long as the app is working, it seems like it'd be a better use of our time to make iterations and updates on iOS and then after several months take what learnings we have and hire a contractor to make the same changes on Android.
Far off in the future updates
If the mobile app is truly a platform we want to support and build on, I think we'll want to hire again at least one full time engineer who can do native Android and as well as keep at least one full time engineer on iOS - much in the same way we have teams supporting and building features on the web.
React Native. I think it's still a compelling tool to use for prototyping, and yea! maybe also for apps that go out into production. But even with our relatively simple use-case here, I came across a couple scenarios where I ended up building native components where the RN JS fell short. I might be wrong, but I think there were a couple of those scenarios on iOS too. If there were a full time Android engineer here, I'd probably suggest converting the React Native code in there right now to its native form after we've confirmed the iteration of the news feed we're using is something that works and we're happy with.
There are benefits to using React Native. I think it's fine still keeping it mixed in with the current app (though the tooling felt a little iffy and the compile times got a bit long on my old machine). Learnings and code can be shared and understood across teams. But to maintain and build and patch any holes where things are missing, an engineer with a native understanding I think is still needed.
Features to Consider
For the most part, I would assume we'll keep parity between iOS and Android features as much as possible. Anyway, in no particular order, a few possible features I would advocate for:
Kudos! I left the code for it in the repo... just in case.
An even more Android-centric UI. More Material UI. Action buttons. Lollipop view transitions. etc
Reminder notifications to report back on campaigns you're signed up for.
Embedding different cards in the news feed. Like maybe one for a one question survey.
I thought a GitHub issue could be a better way of leaving notes that wouldn't get lost in email or Slack. Also totally open to conversation here on it all.
So yea, I'm just gonna brain dump here with thoughts on what next steps for Android dev could be as I and after I transition off the team.
Onboard an internal dev
I think it'd be valuable to have at least one person on the team who could make Android changes and create builds if we're in a bind. I'm particularly thinking about scenarios where a crash is being reported from the app in production and all we'd need is something like a null check to fix it.
The goal would be to have a person whose dev environment is setup, can make code changes and can create builds for debug and release.
Near-term updates
This one's Matt's idea and I agree. I suggest we avoid doing any feature development for Android in the near future unless it's absolutely required. As long as the app is working, it seems like it'd be a better use of our time to make iterations and updates on iOS and then after several months take what learnings we have and hire a contractor to make the same changes on Android.
Far off in the future updates
If the mobile app is truly a platform we want to support and build on, I think we'll want to hire again at least one full time engineer who can do native Android and as well as keep at least one full time engineer on iOS - much in the same way we have teams supporting and building features on the web.
React Native. I think it's still a compelling tool to use for prototyping, and yea! maybe also for apps that go out into production. But even with our relatively simple use-case here, I came across a couple scenarios where I ended up building native components where the RN JS fell short. I might be wrong, but I think there were a couple of those scenarios on iOS too. If there were a full time Android engineer here, I'd probably suggest converting the React Native code in there right now to its native form after we've confirmed the iteration of the news feed we're using is something that works and we're happy with.
There are benefits to using React Native. I think it's fine still keeping it mixed in with the current app (though the tooling felt a little iffy and the compile times got a bit long on my old machine). Learnings and code can be shared and understood across teams. But to maintain and build and patch any holes where things are missing, an engineer with a native understanding I think is still needed.
Features to Consider
For the most part, I would assume we'll keep parity between iOS and Android features as much as possible. Anyway, in no particular order, a few possible features I would advocate for:
cc: @mshmsh5000 @aaronschachter @lkpttn
The text was updated successfully, but these errors were encountered: