Ideas for version 3
See original GitHub issueAt some point, we are going to have to release a BC breaking version in order to fix some inconsistencies in this library. While we’re at it, we might want to rethink the implementation a bit.
Here are some of my findings after having spending some time triaging issues, reviewing pull requests and reading the source code:
Return type inconsistency
Findings:
- getBuildNumber() returns a string on iOS, and a number on Android (#214). Should be a number IMHO
- The windows implementation sometimes returns “not available” when a feature is missing
- Some methods are not implemented at all on a target and causes exceptions when called. Example: getIPAddress()
Proposal:
- No method should throw an exception if not implemented.
- Exception should only be thrown for Android when a permission is missing
- Unimplemented methods should always return
undefined
.
Namespacing
Findings: The API is getting bigger and deals with a lot of mixed stuff (networking, telephony, calendar, …).
Proposal: I think that introducing some king of namespacing could help keeping it tidy:
DeviceInfo.telephony.getPhoneNumber();
DeviceInfo.network.getMacAddress();
DeviceInfo.network.getIPAddress();
// ...
We would also split the native code files by namespace
Naming
Naming is inconsistent: getDeviceName()
vs getBrand()
.
We should take advantage of namespaces introduction to tidy up names.
Multi SIM
Currently, telephony related functions returns data for the first SIM card. Might be good to introduce multi SIM card support.
Same goes for network informations (#259)
Feel free to join the conversation and suggest other or better ideas!
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:33 (1 by maintainers)
Top GitHub Comments
Ok so here’s a first part of the namespacing/renaming I had in mind. I’m pretty sure it can be perfected:
implementation will begin in earnest shortly
That’s the general idea anyway