Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[deviceinfo] Add imeiNumbers property. JB#56945 #23

Merged
merged 1 commit into from Feb 17, 2022

Conversation

spiiroin
Copy link
Contributor

@spiiroin spiiroin commented Feb 4, 2022

As an enabler for deprecating QDeviceInfo class from qt5-qtsysteminfo
package, provide access to device IMEI numbers via DeviceInfo class.

By default imeiNumbers property value gets determined and updated in a
fully asynchronous manner. But to provide behavior that is compatible
with QDeviceInfo it is possible to request synchronous initialization
and make DeviceInfo constructor block until current IMEI numbers
have been fetched.

Signed-off-by: Simo Piiroinen simo.piiroinen@jolla.com

Copy link
Member

@Tomin1 Tomin1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some style related comments. I also looked that those types (e.g. QString and QDBusObjectPath) in arguments thinking if they should be const references but it probably doesn't make much difference here. AFAIK Qt can handle const references just fine in slots but I'm not sure there is any performance difference in practice.

src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
};

DeviceInfoPrivate::DeviceInfoPrivate()
DeviceInfoPrivate::DeviceInfoPrivate(bool synchronousInit)
: m_ofonoTracker(new OFonoTracker(synchronousInit, nullptr))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we actually do this stuff elsewhere? Now the ofono tracking is started for anything using DeviceInfo when none of the existing usage is interested about it. Furthermore this class didn't use to refer to too secrets things, but the ofono side requires permissions -> one could argue anything using this should be having Phone permission.

Maybe this could warrant a separate class?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separate class, having ofono tracking on demand, as singleton, etc would be things to consider if/when the impl is otherwise not bonkers...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the looks of it, libqofono that @monich brought up already has all the low level technical details covered (shared instances, optional blocking, whatnot). I wish I would have known about it a bit earlier... having a new parallel implementation of essentially the same thing with possibility for fresh set of hiccups probably does not make too much sense.

Now, does it also provide a way to "get all imeis" that is easy enough that we can use it as is - without any glue classes?

If not, having a wrapper class that != "DeviceInfo" using libqofono would probably be preferable - any suggestions about naming?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Custom ofono tracking dropped in favor of using libqofono. @monich please check if it looks sane.

Regarding permissions: a process that does not have them, gets empty imei set. Which sounds about right to me. Or at least better than splitting things into multiple interfaces based on current permission requirements, or?

Also changed things so that D-Bus access is done on demand so that no ofono access is done unless imei numbers are queried -> we can still move this to somewhere else, but that would be arch decision rather than technical one.

src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
src/ofonotracker.cpp Outdated Show resolved Hide resolved
@monich
Copy link
Member

monich commented Feb 8, 2022

Out of curiosity, what's the reason for not using libqofono?

@spiiroin
Copy link
Contributor Author

spiiroin commented Feb 9, 2022

Out of curiosity, what's the reason for not using libqofono?

For example: not knowing that such thing exists.

@spiiroin
Copy link
Contributor Author

spiiroin commented Feb 9, 2022

Review commits squashed

@spiiroin spiiroin force-pushed the jb56945_imei_numbers branch 2 times, most recently from dbefc0f to 715651d Compare February 14, 2022 06:12
Copy link
Contributor

@pvuorela pvuorela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure should the imei list be here or in some separate class, but as the usage isn't common and the existing DeviceInfo instances don't now start fetching ofono properties maybe it's good enough to start with. Kind of interesting API, though, when the async version requires to first call getter to return empty list.

*
* Should be functionally equivalent with obtaining data via:
* QDeviceInfo::imei()
* QDeviceInfo::imeiCount()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could myself skip this latter notice as imeis should be equivalent no matter where they are gotten and the usage isn't too widespread. But doesn't matter much.

As an enabler for deprecating QDeviceInfo class from qt5-qtsysteminfo
package, provide access to device IMEI numbers via DeviceInfo class.

By default imeiNumbers property value gets determined and updated in a
fully asynchronous manner. But to provide behavior that is compatible
with QDeviceInfo it is possible to request synchronous initialization
and make DeviceInfo constructor block until current IMEI numbers
have been fetched.

Signed-off-by: Simo Piiroinen <simo.piiroinen@jolla.com>
@spiiroin
Copy link
Contributor Author

Review commits squashed

@spiiroin spiiroin merged commit ca97f23 into sailfishos:master Feb 17, 2022
@spiiroin spiiroin deleted the jb56945_imei_numbers branch February 17, 2022 04:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants