iOS Engs Sync 24 April 2018
iOS Engineer - sync
File sharing
- David enables file sharing to iTunes.
- File sharing is a capability to open app folder (documents) from device
- In Documents, you can see : Realm files, plist (NSUserDefaults), etc.
- Other tool to open folder from iOS Simulator: https://github.com/dsmelov/simsim
Understand crash log
- In Xcode, Window > Devices and Simulators > choose on devices.
- Steps to debug :
- Download IPA & dSYM files and put them in same folder.
- Unzip IPA, find the binary and pull to parent directory (name: Traveloka / Traveloka Staging)
- Unzip dSYM, find the dsym file and pull to parent directory.
Github Discussion
Feedback on using Github during these past weeks..
- Should we enforce code on "stale" reviews? For example, reviewer A has accepted the PR, but the developer pushed a new code that can potentially be different than the one accepted.
- This boils down to reviewer convenience vs security.
- We decided to enforce the reviewer to review again should there be any more changes to the PR – but feel free to voice your opinion if you have any concerns.
- PR commit is not descriptive enough.
- Current recommendation is to avoid naming PR titles as "fix", or "update". Add more descriptions to the commit title and body before merging to your base branch.
- No way to get a filtered view of files that we own (as code owners). When compared to Phabricator, we can easily see our files highlighted in yellow.
- No multi-line comments. Although Github shows the previous 3 lines for context, sometimes it can get a bit confusing to know the scope of code being commented. Don't know why Github doesn't have this feature yet.
- Feedback loop experience on pull request is a bit confusing. As reviewers, it can get a bit unclear whether our comments have been addressed or not.
- To solve this problem, we need to be better understand Github's PR page structure – for example, Github automatically tracks our last review session. When the developer pushes an update, in the bottom of the conversation there should be a "view changes" button that should show only the changes from our last review.
- Pull request templates, are they useful or not? The goal is to help you provide context to your reviewers so it would be faster to review your code. Some PRs still have the default description from template.
- Current recommendation is to put more effort in describing your pull requests. Some sections might not apply to you, and that's fine – feel free to remove the section; don't leave the template as it is.
Some nice features that we can use in Github..
- Milestones. These can be added to any of your open PRs. The goal for this milestone is to provide urgency information for your reviewers – i.e. are they intended for 3.1.0? 3.2.0? etc. Example usage can be seen in https://github.com/traveloka/ios/pull/214
- Issues. Sometimes, you might have concern on how a common component works, or maybe you notice a component that's being used & duplicated in several places but doesn't have a common component, or you simply have concern on our overall development & build workflow. We think that this the right place to gather suggestions from you all.
- Labels. This is another pull request's feature – where we can label our PRs for better categorization. Current existing labels:
wip : Your PR is unfinished, and there might be major changes so it's a bit pointless to review early on.
realm related : Your PR deals with Realm database, for example adding non-trivial migration code, updating Realm in background threads, etc. Infra team will help assist and make sure that the Realm usage is safe.
- There are many labels currently, but feel free to create new ones should you need it.
- Assignees. In general, author should assign themselves to their own PRs. Reviewers can also assign themselves as assignees to make it useful when filtering your PRs.