We will now start by explaining the flow that follows login/registration so that you can understand the context of each required API that helps support the given step.
Worker Home has some logic before it decides what to do and what to render. Specifically there are 2 big IF´s....
- If Setup is not complete (categories, identification, avatar) then force worker to provide,
- If Worker has an active Job then make sure this is finished before accepting new ones
These two components are key in our value proposition. The first solves for security and targeting. The second solves for focus and delivery. A Worker can only have one active job and a worker cannot work if identification hasn't been provided (on the Backend our operators validate information and can block a worker given the need).
Keep in mind that we do not track the actual job, our goal is to make sure clients and workers connect, regardless of the completion or non-completion of the jobs. This is important because some jobs are quick and dirty and others are long and require planning, so it is not fair to block availability for either during this time. Because of this, a job is considered complete when both clients/experts click on the Finish button. They will still be able to contact each other, process payments and evaluate, in a non-linear fashion, but a finished job will not be an "active" job per se anymore.
1. Validate Categories
The first Step to the Worker Home page is to validate that Categories are properly set, otherwise Worker won't be able to receive new job opportunities. Even If this is available for update under profile menu, the app needs to check from Home view in order to continue process.
- meProfile (mode: worker)
- If categories is an empty array then getCategories (mode: worker), else go to validate Identity
- Display Select Categories view in a grid.
- When Worker selects/unselects a category post request to putCategory
- make sure that selected categories remain highlighted
- make sure that the number of categories don't exceed the value from meProfile.MaxCats
- When Continue is pressed, the condition for empty array will be false
2. Validate Identity
The second Step to the Worker Home page is to validate that Official ID is properly submitted, otherwise Worker won't be able to receive new job opportunities. Even if worker can update at a later time and if actual identity validation is not done immediately, the app needs to check the flag for document submission status.
- meProfile (mode: worker)
- if ExpertVerifiedStatus is Cero, identity documents haven't been submitted and you need to show upload view
- The view must validate that two valid image URLs are sent, one for the front and the other for the back of the ID.
- Typically images are stored directly from the app to the container in Firebase and just the reference is passed.
- The fields with the image URLS that you must send to putProfile are expertdocurl and expertdocurl2
- When submitted, expertVerifiedStatus will revert automatically to 1 "submitted" and will pass validation.
It is important that user has image manipulation tools before uploading their images. These tools are simple resize, rotate and crop so that the image best fits a predefined rectangular container/mask.
3. Validate Avatar
The third and final basic validation step for worker profile before moving on to the actual "Home" is to check that expertAvatar exists and is a valid URL with a valid image resource.
- expertAvatar will exist but it can be an empty string or an invalid URL, validation is required on client side.
- If this is the case then an upload avatar view should be presented
- In this View worker can select image from mobile library or take selfie with camera (ideal)
- The photo will be replaced with the avatar, after a client side upload to firebase
- The app will call putProfile with the image URL
- The Flow can now continue to home.
It is important that user has image manipulation tools before uploading their avatar. These tools are simple resize, rotate and crop so that the image best fits a predefined circle container/mask.
4. Active Request
There are two valid states for any given validated worker. Either it is busy with a job in progress, or it is looking for new opportunities. These two scenarios are managed as follows:
- If activeReq is "0" this means that the worker is NOT actively working and is "available" for work
- else, the number returned by activeReq refers to the Work in progress that first needs to be completed.
- If looking for jobs, use the action "getJobs" to return a list of available opportunities, filter them and render them on screen so that Worker can apply or delete.
- If the worker has a job in progress, get all of its details by calling getRequest and display the active view.
- At this stage in either case you must subscribe and Listen to web socket (socketIO) in the channel defined by meProfile.channels (which is similar to the market handle/CountryState)
- Your app now needs to behave based on the messages that arrive by SocketIO. Messages are triggered by the backend when the other app makes an http request and updates information related to the job. Please refer to the guide on SocketIO messaging rules.