Change structure inside UnifiedNlp
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 221
- PR merge metrics
- No merged PRs in 30d
Description
Currently we have the components
- `org.microg:unifiednlp-api`: The UnifiedNlp module API
- `org.microg:unifiednlp-compat`: This is just providing some dummy code for linking to platform internal classes
- `org.microg:unifiednlp-base`: This is all of the unifiednlp logic for all supported android versions
- `org.microg:unifiednlp-app`: This is a wrapper around `unifiednlp-base` to make it a standalone application. It comes in three flavors for specific use cases.
Plan is to create the following component structure:
- `org.microg.nlp:api`: Same as `org.microg:unifiednlp-api`
- `org.microg.nlp:compat`: Same as `org.microg:unifiednlp-compat`
- `org.microg.nlp:service`: Version independent service with unifiednlp logic connecting to the modules.
- `org.microg.nlp:client`: Client library to directly interact with `org.microg.nlp:service`.
- `org.microg.nlp:location-v1`, `org.microg.nlp:location-v2`, `org.microg.nlp:location-v3`, `org.microg.nlp:geocode`: Separated implementations of each protocol version of nlp and geocode, each using `org.microg.nlp:client`
- `org.microg.nlp:fused`: New implementation of the fused system provider (not the fused gms provider) using `org.microg.nlp:client` and system gps
- `org.microg.nlp:app`: With various flavors to include a subset of the previous components (LegacyProxyToGms, LegacyStandalone, NewStandalone, ServiceStandalone)
Rationale:
- Increase stability by having system provider out of UnifiedNlp process
- Don't have to "run" UnifiedNlp twice on legacy devices with gms
- Allow fused gms provider to directly talk to UnifiedNlp service without system intermediary via `org.microg.nlp:client`
API for modules stays the same, no action needed from module developers.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by mapping the existing unifiednlp-api, unifiednlp-compat, unifiednlp-base, and unifiednlp-app modules. Compare that structure with the proposed api, compat, service, client, protocol, fused, and app components. Done means the planned separation is implemented, the listed app flavors work, and module APIs remain unchanged for developers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100