Library Simplified is a collection of middle-ware, server software and mobile client applications for iOS and Android.

The pages below document various best practices and workflows important for anyone contributing to the mobile client applications. What's considered a best practice will no doubt evolve over time, as should this document.

But first, a bit of wisdom.

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! — PEP 8 -- Style Guide for Python Code

Mobile Repositories

Android

Code style

We use a mix of Java and Kotlin when developing applications for Android. New work should generally be done in Kotlin, where appropriate. When touching existing code do your best to match the code style of the file you're working on.

New Kotlin code should adhere to the Kotlin Coding Conventions and Android style guide.

We use a tool called ktlint to enforce a consistent code style. You can run this check against your code using the command ./gradlew ktlint.

The Google Java Style Guide is a good reference when writing new Java code.

Books we recommend

iOS

Dependent frameworks that we maintain

Code style

We use a mix of Swift and Objective-C when developing applications for iOS. New work should be done in Swift, whenever possible and appropriate. For example, if you need to write a significant amount of Objective-C code to fix a bug or extend a feature, we strongly prefer to write the same functionality in Swift, even if it costs a bit of refactoring work.

Swift code should adhere to Google's Swift Style Guide, which is based on Apple's Swift standard library style. Regarding API design and naming in particular, please follow Swift's API Design Guidelines.

Objective-C code should follow Apple's Conventions and more in detail Google's coding style.

When touching existing code, match the code style of the file you're working on, unless for some reason its code style differs greatly fro

m the guidelines listed above. In that case, fix the formatting of the whole file if possible (filing a subtask on Jira) before adding new code to it.

GitFlow

Historically, we've used git flow as our basis for branching and tagging releases.

We recommend installing Git Flow AVH Edition to automate some of the work of branching and tagging. Using gitflow-avh is not required, but by automating the underlying repository operations, it eliminates the possibility of making mistakes, and keeps the various branches consistent.

Steps

1. Run Ktlint

2.  Create feature branch using task number


3. Create pull request

4. Complete pull request template

5. Github tags

6. Single approval

QA Process



Release Process

The release process today can be a bit confusing; challenges come up because we have two different platforms that are not always in sync (iOS/Android), and both of those require approvals from the Apple App Store and the Google Play Store, respectively. The Release processes, along with some other technical documentation, can be found by the Mobile team here.

Pre-Release Steps

  1. Three to five working days before the targeted release date, depending on the size of the release (bug fix or feature), a code freeze goes into effect where no new additions are added to the codebase.
  2. After all tickets for the release have been merged into develop, create a new release branch, e.g. git checkout -b release/3.6.0 and push it upstream.
  3. Verify all unit tests are passing
  4. Verify all tickets have been moved into the Ready for QA state in Jira. The completed tickets serve as the basis for QA release notes notifying QA of what tickets should be tested.
  5. Create pull request against master from the release branch.
  6. Create QA build/release candidate and upload to Firebase, Google notifies testers that the build is available
  7. (iOS Only) Stage release candidate in App Store Connect and set to manual release

Current State Release Steps 

iOS

  1. Get the sign off from QA for the build from Joseph Dalton
  2. Based on commit history and completed Jira tickets, construct text to be shown in the What’s new field in the App Store. This text should be approved by Risa Wolf in Jira ticket or official email for visibility.
  3. Check with Risa Wolf to see if there are any new screenshots that should be added to the App Store listing.
  4. Add the approved Whats new text to the App Store listing.
  5. With product team approval, manually release previously approved production build in the App Store.
  6. Notify #Simplified channel in the NYPL Digital Slack workspace that the release has gone out.

Android

  1. Get the sign off from QA for the build from Joseph Dalton
  2. Based on commit history and completed Jira tickets, construct text to be shown in the What’s new field on Google Play. This text should be approved by Risa Wolf in Jira ticket or official email for visibility.
  3. Check with Risa Wolf to see if there are any new screenshots that should be added to the Google Play listing.
  4. Increment version name and number, tag release branch in Github.
  5. With product team approval, run Fastlane commands to upload the build to Google Play, enter approved Whats new text and any new approved screenshots. Use the release version as the internal release name.
  6. Resolve any new Google Play Console errors or warnings.
  7. Notify #Simplified channel in the NYPL Digital Slack workspace that the release has gone out.


Post Release Steps

  1. Merge release branch into master
  2. Monitor Crashlytics 
  3. Monitor email error reports
  4. Respond to any negative Google Play Store / Apple App Store reviews where their specific issues have been addressed in the latest release






  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.