Notices


Reply
Thread Tools
Posts: 207 | Thanked: 482 times | Joined on Mar 2016
#151
yeah, i think this is it, see https://developer.pebble.com/guides/...#account-token
If the user is not logged in, the token will be an empty string
Since we don't give users ability to login - the accounToken is always empty, and the current implementation is faking it:
Code:
    // We do not have any account system, so we just fake something up.
...
    if (token.isEmpty()) {
        token = QUuid::createUuid().toString();
It means all apps relying on account token won't work till we fix that. It also means that current implementation guarantees anonymity %)
unfortunately my mitmproxy dump from android has been done with already logged in account, so I don't have that exchange captured. Need to re-iterate the process.
BTW it was the same on pebbled, the implementation in jskitobjects.cpp is identical,
 

The Following 5 Users Say Thank You to ruff For This Useful Post:
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#152
Supporting accounts would need support in the QML appstore client, and then in libpebble to remember the account id and make it available to apps. Both of those should probably be done in collaboration with RockWork - I don't want to keep fairly in line with that so we can both benefit from bug fixes on either side.

From a libpebble standpoint the code would probably be identical in RockWork and RockPool, but what about the appstore client?

Originally Posted by ruff View Post
BTW it was the same on pebbled, the implementation in jskitobjects.cpp is identical,
I think some people believe that there's not much of Pebbled left in RockWork. A lot has been replaced and refactored, but it's important to appreciate that is it really still a fork, and those guys deserve contribution credit.
 

The Following 2 Users Say Thank You to abranson For This Useful Post:
HtheB's Avatar
Moderator | Posts: 3,716 | Thanked: 7,419 times | Joined on Dec 2009 @ Bize Her Yer Trabzon
#153
Originally Posted by ruff View Post
yeah, i think this is it, see https://developer.pebble.com/guides/...#account-token

Since we don't give users ability to login - the accounToken is always empty, and the current implementation is faking it:
Code:
    // We do not have any account system, so we just fake something up.
...
    if (token.isEmpty()) {
        token = QUuid::createUuid().toString();
It means all apps relying on account token won't work till we fix that. It also means that current implementation guarantees anonymity %)
unfortunately my mitmproxy dump from android has been done with already logged in account, so I don't have that exchange captured. Need to re-iterate the process.
BTW it was the same on pebbled, the implementation in jskitobjects.cpp is identical,
What about like an option to enable it for those who doesn't care about privacy?
(Joke aside, I would love to get some apps to work )
__________________
www.HtheB.com
Please donate if you think I'm doing a good job.
 

The Following 2 Users Say Thank You to HtheB For This Useful Post:
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#154
Yep it should be on the to-do list, and I think as the docs say it should be empty if the user isn't logged in, rather than a random string. It'll have to be discussed with the RockWork guys though. A common implementation would be better.
 

The Following 2 Users Say Thank You to abranson For This Useful Post:
Posts: 207 | Thanked: 482 times | Joined on Mar 2016
#155
Originally Posted by abranson View Post
From a libpebble standpoint the code would probably be identical in RockWork and RockPool, but what about the appstore client?
We're also reusing native code implementation from rockwork mostly, of course we have own platfrom layer in main.cpp but the rest is mostly as-is. We can rename main.cpp to rockpool.cpp to avoid conflicts and then keep rest of the code shared.
Our QML part is also independent now since we've moved it to sailfish-specific dirs (pages/covers).
It's a pity we don't have track log for bazaar - so we cannot say what actually changed since initial import. And unfortunately during the initial import you didn't preserve original state so we also don't have a track of how far we deviated from them during the import.
From what I can see we have only servicecontrol.cpp, pebble.cpp and main.cpp (of course) changed since initial import.
These are topics to settle down if we targeting the merge though.
 

The Following 4 Users Say Thank You to ruff For This Useful Post:
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#156
Originally Posted by ruff View Post
We're also reusing native code implementation from rockwork mostly, of course we have own platfrom layer in main.cpp but the rest is mostly as-is. We can rename main.cpp to rockpool.cpp to avoid conflicts and then keep rest of the code shared.
Our QML part is also independent now since we've moved it to sailfish-specific dirs (pages/covers).
It's a pity we don't have track log for bazaar - so we cannot say what actually changed since initial import. And unfortunately during the initial import you didn't preserve original state so we also don't have a track of how far we deviated from them during the import.
From what I can see we have only servicecontrol.cpp, pebble.cpp and main.cpp (of course) changed since initial import.
These are topics to settle down if we targeting the merge though.
Bzr and Git can co-exist in the same directory if you want to explore the differences. That's what I do to push changes back to RockWork. Pull from git, sync some changes, push to launchpad. Of course that doesn't cope when the files have been moved.
 

The Following 3 Users Say Thank You to abranson For This Useful Post:
Posts: 207 | Thanked: 482 times | Joined on Mar 2016
#157
Oh, excellent, so you should be in a better position to say what has changed
We can probably merge pebble and servicecontrol files, just need to move service name definition to some external file, bcz changes there are mostly fixes (missing calls).
We could even make libpebbleclient.so lib and strip down platform part to mere initialization.
 

The Following 3 Users Say Thank You to ruff For This Useful Post:
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#158
Originally Posted by ruff View Post
Oh, excellent, so you should be in a better position to say what has changed
We can probably merge pebble and servicecontrol files, just need to move service name definition to some external file, bcz changes there are mostly fixes (missing calls).
We could even make libpebbleclient.so lib and strip down platform part to mere initialization.
I would be if you hadn't moved all the qml files
 

The Following 2 Users Say Thank You to abranson For This Useful Post:
Posts: 207 | Thanked: 482 times | Joined on Mar 2016
#159
But QMLs are out of the scope, they are all different and platform specific, you can return original qml files from bazaar if bzr is complaining - original were in the client's root folder(rockwork).
 

The Following 2 Users Say Thank You to ruff For This Useful Post:
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#160
Originally Posted by ruff View Post
But QMLs are out of the scope, they are all different and platform specific, you can return original qml files from bazaar if bzr is complaining - original were in the client's root folder(rockwork).
Ok, so if we implemented an account login in our version of the store client, it wouldn't be very useful to RockWork?
 

The Following 2 Users Say Thank You to abranson For This Useful Post:
Reply

Tags
pebble, smartwatch


 
Forum Jump


All times are GMT. The time now is 10:31.