This App is intended for Senior candidates. There are Android and iOS variants of this mobile payment App in the respective project directories. This application may include intentional compiler errors out-of-the box, and many of the functions and screens described below are currently not implemented.
| Login Screen | Order Entry |
|---|---|
 |
 |
- Create your own repository to store this project and all of your work.
- Fork or Clone this repository (GroovyPaymentApp-Dev) to your local machine, and then push your work to your repository using the instructions and CLI commands below for guidance:
# Fork this project, and clone your fork to your local machine
git clone git@github.com:USERNAME/FORKED-PROJECT.git
# To make a full copy (duplicate) of this repo without forking:
# Navigate to your Github dashboard. Go to 'Your Repositories'.
# Create a New Repository. Name it anything you'd like.
# You can make it public or private.
# Do not initialize the repository with a README.
# Do not add a .gitignore. Do not add a license.
# Clone this source repo onto your local machine.
git clone git@github.com:HelloImKevo/GroovyPaymentApp-Dev.git
# Navigate into the new Git project directory.
cd GroovyPaymentApp-Dev
# Check what the current remote repository URL is:
git config --get remote.origin.url
# Change the remote repository URL to your personal repository:
git remote set-url origin git@github.com:YOUR_USERNAME/YOUR_REPOSITORY.git
git config --get remote.origin.url
# Push the entire contents of the Groovy Mobile Payments project to your personal repository:
git push
# If you want to validate your Git environment is set up correctly, make a change to any file, then:
git add .
git commit -a -m "Minor update to <file_name> file"
# Should say something like 'Your branch is ahead of 'origin/master' by 1 commit'.
git status
# Push your new commit to your remote Git repository for funsies.
git push
- More repository management discussions:
- Your repository can be public or private, but if it's private you'll need to adjust the repository settings to invite one or two of us as collaborators so we can review your commits.
- This is optional, but if you want good feedback on your submitted solutions you can create a Pull Request (in your repository) and notify us when it is ready for review. There's an example Pull Request in this repository for reference: https://github.com/HelloImKevo/GroovyPaymentApp-Dev/pull/2
- Additional information can be found under the Git Workflow References section.
- Create a Stripe Developer Account over at: https://dashboard.stripe.com/register
- Grab your Publishable and Secret API keys from your dashboard: https://dashboard.stripe.com/test/apikeys
- The Stripe SDK architecture is built around the expectation of using a Client-Server model, where the Client (Mobile App) uses a Publishable API key, and the Server uses a Secret API key to generate a Client Secret string. We don't have a Server for this test application, so we emulate the "Server" within our app. The Android and iOS applications both use asynchronous utilities for generating a Client Secret using the Stripe Secret API key.
- Okay, phew. If you made it this far, you're in good shape 👍 hopefully that stuff didn't take too much time (it gets easier with practice).
- This project is comes with a Business Requirements Document (BRD) that is modeled after real-world business requirements. It is effectively a coding assessment designed to help us identify your Skills and Areas of Expertise and Attention to Detail, while providing you a little bit of exposure to the payments industry and our Git Workflow.
- We recommend spending about 8 Hours implementing solutions to any number of the Business Requirements listed below, but you are welcome to spend as much time as you'd like to accomplish any number of the tasks.
- It is suggested that you work on tasks that demonstrate your strengths as a developer. For example, if you've got a lot of familiarity with Encryption & Decryption mechanisms, you might want to implement an encryption framework for the
User.Passwordmodel data for the login flow. Alternatively, if you enjoy working with multi-threaded systems, feel free to rewrite the SQL Database implementation or the asynchronous network calls to the Stripe API.
- After you push commits to the project, our team will Review your work and provide Constructive Feedback on how to improve your code readability, code organization, your approach to solving the problem, or sometimes we will just banter about random technology trends or the latest data breaches 😬
- Oftentimes, code style is Subjective, and there's no right or wrong answer, and that's okay! If you disagree with our feedback, let us know why you wrote it that way - we look forward to learning new things and better practices from you 😁
- Code style and consistency is important to us - we take pride in every line of code we write, and encourage you to do the same. The Android team generally adheres to all AOSP Contributor Guidelines (See: Android README) and the iOS team generally adheres to all iOS Contributor Guidelines (See: iOS README).
- Android submissions can be written in Kotlin or Java.
- iOS submissions can be written in Swift or Objective-C.
- We are more interested in the Quality of your submissions, rather than the quantity of submissions. Quality is assessed using some of these parameters:
- Is the Code Style consistent? (Do variables follow the same standard conventions? Is the code formatted with the same indentation levels?)
- Is the Git History clean and well-organized? Can we run a
git log --onelineand figure out how the candidate implemented their solution for the task? Recommended reading: https://chris.beams.io/posts/git-commit/ - Are the methods / functions designed to be small and Focused? (It is, however, recognized that long methods are sometimes appropriate.)
- Is complex or obscure logic Documented? Are comments used effectively?
- Does the Code Architecture follow recommended developer patterns?
- Does the Android code use K&R bracing style? https://en.wikipedia.org/wiki/Indentation_style#K&R_style
- Does the iOS code use Allman bracing style? https://en.wikipedia.org/wiki/Indentation_style#Allman_style
- Like many other successful companies, we aim to follow a Test-Driven Development paradigm. Unit Tests and Instrumentation tests are strongly encouraged!
- For any company-related or interview-related questions, reach out to your point-of-contact (likely a Hiring Manager).
- If you would like to keep your work in a private repository, please notify the Hiring Manager, and they will provide you a list of email addresses for the code reviewers that you'll need to invite as collaborators to your repository.
- If you have technical questions or need assistance with this project, ask the Hiring Manager, and they will provide you with the email addresses of one of our team members, and you can email us your question directly, and we will do our best to help.
| Requirements | Business Mock |
|---|---|
The application currently crashes when a Placeholder button is clicked on the main dashboard. Design an alert dialog that is shown with an "Under Construction" type of message instead of crashing. |
 |
| Requirements | Business Mock |
|---|---|
| Users of this application have complained that the Product list looks very bland. (We've gotten lots of negative feedback on the Google Play Store and Apple App Store) Update the style of the products to match this new mock from the Design team as closely as possible (or use your creativity to implement a better design). |
|
| Requirements | Business Mock |
|---|---|
| Google Play Store users have left us lots of negative feedback because the application only supports English and Spanish. For this task, localize all of the app's string resources to another language of your choice. Go through the app and extract any hard-coded strings as necessary. |
 |
| The system language can be changed at Runtime under System settings. |  |
| Requirements | Business Mock |
|---|---|
Load the Cart models from the database and display them in Order History. |
 |
| Requirements | Business Mock |
|---|---|
| Currently, there is no way to complete the Checkout flow, because we haven't implemented Cash or Credit support. The "Pay with Cash" screen has a 10-digit Keypad, but it isn't wired up. show the User how much Change is Due to the Customer. |
 |
| Requirements | Business Mock |
|---|---|
| Currently, there is no way to complete the Checkout flow, because we haven't implemented Cash or Credit support. The "Pay with Credit" screen has a Stripe CardInputWidget, but it isn't wired up. Every Stripe payment requires a Client Secret string to be generated (the Client Secret is derived from the transaction amount, the currency type, and your Publishable API Key), so you'll need to generate a Client Secret when the User clicks the PAY (CREDIT) button, and then process the payment using com.stripe.android.Stripe.confirmPayment(). References: https://stripe.com/docs/payments/accept-a-payment#android https://stripe.com/docs/testing |
 |
| Consider logging or displaying the response from Stripe. |  |
| Requirements | Business Mock |
|---|---|
| When the Customer finishes paying for the Order, navigate to the Checkout Complete screen. |
 |
| Requirements | Business Mock |
|---|---|
Generate some UserEntity records and implement a proper login flow! |
|
| Show details about the currently logged in User on the User Profile screen. |  |
| Requirements | Business Mock |
|---|---|
| Use any open-source Charts & Graphs library to represent any type of data you'd like. References: https://github.com/PhilJay/MPAndroidChart https://github.com/AnyChart/AnyChart-Android |
 |
Useful git commands for quickly traversing repos:
# Display your git configuration
git config --list
git config --global -l
# Display all remote branches
git branch --remote
# Concise view of git history
git log --oneline
# Visual graph of git history
git log --oneline --graph --all --decorate --abbrev-commit
# See how many lines of code you've changed
git diff --shortstat
# Pushing from a local repository to GitHub hosted remote
git remote add origin git@github.com:USERNAME/REPO-NAME.git
# Clone your fork to your local machine
git clone git@github.com:USERNAME/FORKED-PROJECT.git
# Creating a new remote branch
git checkout master
git pull
git checkout -b pr-task-solution
git push -u origin pr-task-solution
# Remove a git ignored file that is being tracked
git rm -r --cached .
git add .
# Stash your local changes
git add .
git stash save "Implement solution for Task 001 - Work in progress"
git stash apply stash@{1}
# Preview your stashed changes
git stash list
git stash show -p stash@{1}
# Un-commit and stage changes from most recent commit
git reset --soft HEAD~1
- Github pull request reviews documentation: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews
- Useful link about project forks: https://gist.github.com/Chaser324/ce0505fbed06b947d962
- Great YouTube video tutorial "Creating a Simple Github Pull Request" by Jake Vanderplas: https://www.youtube.com/watch?v=rgbCcBNZcdQ
# List all remote pull requests
git ls-remote origin 'pull/*/head'
# Fetch a specific pull request into a local branch and with a custom name
git fetch origin pull/2/head:pr-new-feature
# Fetch a pull request from a fork repo and patch it as a local branch
git fetch git@github.com:vikvelma/ForkedPaymentApp.git refs/pull/3/head:pr-forked-feature
Many thanks to the contributors and maintainers over at game-icons.net 😂 it has been an extremely helpful resource in prototyping mobile applications.
https://game-icons.net
https://stripe.com/docs/development