search

opendroneid / receiver-android

Example Android receiver application for unmanned aircraft Remote ID
Apache License 2.0
188 stars 61 forks source link

Find out the appropriate sorting mechanism for supported devices. #15

Closed lukasbrchl closed 3 years ago

lukasbrchl commented 3 years ago

The list of supported devices for receiving the DRI signals is now unordered. It would be nice to have some logical order so that people can find their devices easier.

Suggestion from @janusw

Wouldn't it be useful to sort the list in some way? Currently I see no particular order, except for the fact that Samsung comes first and brands seem to be aggregated in blocks :)

Possible ordering schemes that come to mind:

  • alphabetical by brand/model
  • degree of support
  • chipset
  • ...
janusw commented 3 years ago

Thanks for the carryover, and sorry for trying to hijack PR #14 for discussing this :)

lukasbrchl commented 3 years ago

From my point of view, I would prefer sorting based on multiple criteria. 1) Sort by the manufacturer from A to Z 2) Sort by the model series where flagships are at the top (e.g. Note 10, Note 9, Note 8, S20, S10, S9, A5)

Notes:

janusw commented 3 years ago

From my point of view, I would prefer sorting based on multiple criteria.

1. Sort by the manufacturer from A to Z

2. Sort by the model series where flagships are at the top (e.g. Note 10, Note 9, Note 8, S20, S10, S9, A5)

Sounds good.

Notes:

* New phones should be at the top because they will be the most relevant for the viewers.

Yeah. So maybe it would make sense to add a column for the Android version that was used for the test, and use this as a secondary sorting criterion? Newer OS usually means newer phone :)

* I don't know how to cope with tablets.

I don't think it is worth to make a separate table for tablets, so just add them into the mix with the smartphones (using the same sorting criteria, of course).

friissoren commented 3 years ago

If we add the Android version, we do have that data for many of the devices, since it was in the original Excel sheet.

Now when adding screenshots, the Android version is visible also in the nRF Device Information.

For WiFi Beacon, my understanding has been that it is supported for all phones running Android 8 or newer. But I don't have a transmitter, nor a receiver implementation for that so I can't say for sure.

janusw commented 3 years ago

If we add the Android version, we do have that data for many of the devices, since it was in the original Excel sheet.

You do? That's good. One more reason to add it (I was worrying how to get it for all the listed devices).

Now when adding screenshots, the Android version is visible also in the nRF Device Information.

That's good as well, then we do have it for every device with a "proof".

For WiFi Beacon, my understanding has been that it is supported for all phones running Android 8 or newer. But I don't have a transmitter, nor a receiver implementation for that so I can't say for sure.

I think it's actually WiFi Aware / NAN that requires Android 8 ...

friissoren commented 3 years ago

I think it's actually WiFi Aware / NAN that requires Android 8 ...

No. WiFi aware/NaN is HW/driver specific (as can be seen from the table content). E.g. even the brand new One Plus devices still don't support it.

But WiFi Beacon is based on the SSID broadcasts that all HW can pick up, so it just needs the necessary Android APIs (I think) to pick it up. I don't know what exact API that is though.

janusw commented 3 years ago

I think it's actually WiFi Aware / NAN that requires Android 8 ...

No. WiFi aware/NaN is HW/driver specific (as can be seen from the table content). E.g. even the brand new One Plus devices still don't support it.

Well, might be that it also requires support from the HW/driver, but in any case this page clearly lists Android 8 as a requirement: https://developer.android.com/guide/topics/connectivity/wifi-aware I guess that means that Android 8+ is required, but not all Android 8 devices will support it, right?

But WiFi Beacon is based on the SSID broadcasts that all HW can pick up, so it just needs the necessary Android APIs (I think) to pick it up. I don't know what exact API that is though.

I don't know either.

lukasbrchl commented 3 years ago

I am still not a fan of adding the Android version in the column. What is the best thing that would help us? Feel free to convince me. But right now, I would prefer to keep the table compact

janusw commented 3 years ago

I am still not a fan of adding the Android version in the column. What is the best thing that would help us?

Well, I don't have a very concrete argument for it at this point. It's more of a feeling that this is relevant information, and that it might bite you at some point if you leave it out. From experience, surprises tend to happen more often than you anticipate ;)

It might actually help to clarify empirically whether a particular Android version is required for WiFi NAN and/or WiFi Beacon (see discussion above).

Also, IIUC, it might easily happen that a device's behavior regarding one of the listed features changes with the Android version, e.g. by a change of API or by changes in a driver etc. I don't have any hard evidence for this right now, but I would assume it's quite probable.

Given the fact that you apparently have the data for most devices in the table (according to @friissoren) and you will get it for every device that's added with a proof, I would definitely tend toward including it.

Feel free to convince me. But right now, I would prefer to keep the table compact

For one thing, the additional column would not take up much space. It will just contain a single number (e.g. 9, 10 or 11).

Another idea to make the table more compact might be to leave out the "proof" column, and instead link to the screenshots directly from the four columns (e.g. making the column text appear as a link if the screenshot is available). That will lead to slightly more text in the markdown source, but to a more compact rendering and more direct links to the screenshots.

Along this line, one could actually replace the "proof" column by an OS version column, so that the table would not become less compact ...

janusw commented 3 years ago

So, anyway, I don't want to pressure this too much. If you don't want to add the Android version, that's fine with me. It was just a suggestion from my side :)

@lukasbrchl Starting with the sorting scheme you proposed would be an improvement already. Are you planning to take action with that, or should I take care of it?

lukasbrchl commented 3 years ago

Well, I'm not an expert on smartphones so it would take me a lot of time to Google all the details about model series and flagships. I don't plan to do it in the near future just myself. But of course, I can help with a review

janusw commented 3 years ago

Well, I'm not an expert on smartphones so it would take me a lot of time to Google all the details about model series and flagships. I don't plan to do it in the near future just myself. But of course, I can help with a review

Well, ok. I made a start with something we should all be able too agree on: sorting alphabetically by manufacturer (see #22). Reviews welcome :)

Regarding a possible secondary criterion, I don't think we should use something too complicated, which needs a lots of googling or whatever. It should be rather obvious. The Android version would be a perfect candidate IMHO ;)

lukasbrchl commented 3 years ago

Thanks for this first step. Looks fine to me so I merged it

friissoren commented 3 years ago

Uploaded PR #24, which adds the Android version for most of the devices.

friissoren commented 3 years ago

If you don't mind, I will consider this issue as done. Of course, second level sorting could be added but there are not that many phones in the list, so it should be possible to find them the way they are sorted now. We can re-open this issue or create another if you deem it necessary.