Closed Julesssss closed 1 year ago
Triggered auto assignment to @NicMendonca (NewFeature
), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.
Hey @NicMendonca, SWM are going to work on this, so no UpWork issue is required.
As agreed on Slack we're gonna start with adding two build types (or flavors) with different applicationId than staging and production (they share the same one).
Hey, I'd like to inform that I'll be working on this issue :)
Hey @staszekscp, that's great! Nice to meet you.
So, starting with the environment mapping, I believe this is our current build env config:
Android build variants
release: production app
e2eRelease: clear traffic build for automated performance testing
internalRelease: internal testing for beta channels, Applause testing, and browserstack(?)
debug: local dev builds
iOS packaging(?) I'm not exactly sure how this works today, I can't see any buildScheme configured π
production: production app/testflight
staging|internal: dev builds
I think we're aligned on allowing these three variants to be installed simultaneously. This would be consistent for Android, iOS, and Desktop:
Expensify Chat
: [production|staging] PlayStore/App Store/Testflight/Production Desktop builds
com.chat.expensify.chat
, Android: com.expensify.chat
Expensify Chat AdHoc
: [internal|ad-hoc] Internal testing via ReadyToBuild browserstack label
com.expensify.chat.adhoc
, Android: com.expensify.chat.adhoc
Expensify Chat Dev
: [env pulled from local .env
file] local developer builds for internal employees and external contributors
com.expensify.chat.dev
, Android: com.expensify.chat.dev
Hey @Julesssss! As a follow-up from Slack to keep everything in the issue: Could you add com.expensify.chat.internal
and com.expensify.chat.dev
projects to Google Services? Without that Iβm afraid I wonβt be able to build android app.
Hey @staszekscp, yep no worries. I created an issue for our infra team to create the environment and will update you as soon as this is ready. If I recall correctly, I'll also need to share the updated google-services.json
file with you π
Okay, I created all of the new apps in Firebase. @staszekscp I'll send you the files via Slack
Oh one more thing. Lets just use AdHoc
instead of internal
We merged the first issue (badge), progress ongoing
Hey @Julesssss , I think everything works nicely, I would only have one request - could you provide Dev/AdHoc versions of the splash screen logo? I would like to include there badges with DEV
or ADHOC
depending on the build type. When it's implemented we could have a short round of tests :)
Hey, yep no problem. I created an internal issue here. Will report back once I have the assets.
Files:
Hey @staszekscp, is there anything I can help with here?
Hey @Julesssss! Sorry for lack of update - I was asked to focus 100% on the navigation reboot. I may find some time next week, but if not, I'm going to hand it to someone in SWM. As I've mentioned some time ago, most of the job is done, but I bumped into some issues with integrating correct splash screen on iOS builds, and I didn't have time to investigate it properly π
Looks like something related to react-navigation
may have been mentioned in this issue discussion.
As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js
files should not be accepted.
Feel free to drop a note in #expensify-open-source with any questions.
Hey @staszekscp, that's no problem. We can wait a bit longer. Hope you're enjoying App.js!
Excited for this to pick back up π
Since @staszekscp is busy with other assignments, I will be taking it over. There are some questions to be answered:
Hey @mczernek π
My only concern is that we'll have a total of 4(flavour) * 2(build type) variants, a lot of which will be useless given that our environments are configured in JS. I know this is the correct way to configure varients though, so as long as we can keep the total variant number low, I'm happy.
Is your suggestion to switch to something like this? Where β is a useful variant? and β will be unused.
Current | flavour | |
---|---|---|
debug | β | |
e2eRelease | β | |
e2eInternal | β | |
release | β |
Planned | v flavour v / > build type > | release | debug |
---|---|---|---|
default | β | β | |
AdHoc | β | β | |
Dev | β | β | |
e2e | β | β |
Hey @mczernek, just wanted to check the above is accurate?
I'm still excited to make progress with this task, we're just awaiting availability on SWM's side.
Hey, I'm from SWM and I will help with this task.
Hey @kowczarz. That's great.
Here's where we're at, we just need to confirm that this flavour categorizationwill work for us on Android.
Yes, I think this categorisation works, we will disable unused variants, so we will have 6 of them.
I've just asked a question in a slack thread https://expensify.slack.com/archives/C01GTK53T8Q/p1687424434878779?thread_ts=1680176779.298009&cid=C01GTK53T8Q
WeNot overdue, we're discussing the above comment in Slack
We're discussing the options for iOS here in Slack:
Well basically targets are much much more powerful. They allow you to basically define each file in a per target base - you can substitute any resource, Info.plist or even implementation files.
They are generally used to define multiple apps or distributions from one codebase. In that manner they are very similar to androidβs flavors. However, some iOS devs consider them to be misused very often. I came across some very strong opinions that changing only environment (and icon) is not enough to setup new target and introduces unnecessary confusion and complexity. They say that targets should be reserved for cases like building watchOS and iOS apps from the same codebase. I generally disagree and would lean towards targets as a go to solution, especially if weβre facing any limitations now.
If we stick with buildScheme we might encounter situation in the future that we could do something on android with flavours but buildSchemes would limit us from achieving the same thing on iOS. At the same time I can totally understand someone who sees that as preoptimisation.
TL;DR: In my opinion we should use targets as they are more powerful, but some iOS devs might disagree.
@Expensify/mobile-deployers can you please share your thoughts on the following options:
TLDR: A) Use buildScheme: Provides fewer features, but is often preferred by iOS devs B) Use targets: Simpler implementation? More powerful. Might make it harder to use targets for watch/vision apps in the future
In discussion on slack we chose, we will be using buildScheme.
Making good progress. Currently held while I create/update the iOS provisioning profile. Based on this comment I need to change the packageID, but obviously this will break the current flows... Likely need to create a temp one
For iOS we'll need a new App, so the next step is to create a new app for the AdHoc flavour and retest the WIP PR.
Today I created a new AdHoc identifier and provisioning profile. Next step is to share the provisioning profile with SWM and to retry the iOS build.
Today I recreated the provisioning profile to match our existing case formatting. Then I encrypted the profile and submitted the PR for review.
Installed multiple apps on a physical device for the first time today π
It's a dream come true π₯²
PR is looking good, I just requested some asset re-imports to fix a border issue. AdHoc builds are installed side-by-side on both iOS and Android nicely.
Tomorrow I'm going to try the dev builds. I'll also need to configure the iOS provisioning file for .dev
:
PR is testing well on Android also. Just requested a few small fixes:
Today I verified the npm run ...
commands would build the correct flavor. I think the final task now is to fix the splash screen π
I think we're very close to being able to merge, we just need this splash screen icon issue to be resolved.
PR is looking good, we made a few small changes today.
Just to let you know I'll be away until Monday. I'm hoping to run the final tests and review on Monday, then after merging will quickly follow up with the icon PR update.
This also means that I will be online when the changes go live and I can explain the changes to everyone π
Hey @kowczarz, just bumping a few final conflicts and comments
Testing this today along with @allroundexperts
Getting very close now:
Remaining tasks:
iOS | Android |
---|---|
Job added to Upwork: https://www.upwork.com/jobs/~01a69dd286c1e8c009
Triggered auto assignment to @twisterdotcom (External
), see https://stackoverflow.com/c/expensify/questions/8582 for more details.
Current assignee @allroundexperts is eligible for the External assigner, not assigning anyone new.
P/S from @mczernek
Problem
As a developer when working on mobile applications I cannot have two versions of the App being installed at the same time, even when one of them is staging and the other is a production app. I want to be able to have a production app installed at all times and simultaneously install new versions of the app I am working on. I want to be able to easily distinguish between both installed apps.
Solution
Both iOS and Android prevent users from having the same app installed twice on the device. This is determined by bundleID on iOS and applicationID on Android. In order to have multiple apps we need to alter their ids.
Upwork Automation - Do Not Edit