A push should be dependable, it should be guaranteed to be seen the next time I boot up the receiving device. This is the one thing that forces me to keep Pushbullet on all my devices.
This is now available in the latest beta.
I've just tested this and it doesn't seem to work 100%. If I turn off my PC and send 2 or 3 pushes in a row, when I reopen Chrome, some of them are lost. It seems kinda random, but the last one is almost always lost, I get only the first and maybe second ones.
Using the chrome extension v1.77 and Chrome 59.0.3071.115.
How long do you wait between sending the pushes and opening Chrome?
I just tried it. Sent 5 pushes and waited about 15 seconds. After opening Chrome only the last one was there (weird, I thought I would only get the first one), and only the last one in the device's history as well.
How exactly did you send the pushes? Thanks for the feedback
1 - Close Chrome
2 - Head to the Join App in my smartphone
3 - Devices - My closed Chrome device
4 - Write 5 messages
5 - Wait 15 seconds
6 - Open Chrome again
If you're still not able to reproduce it, please say so, I will try to provide more info
Oh, ok, so to confirm you are sending clipboards? Do you really need those to have guaranteed delivery? :) thanks again
I'm sending pushes...I come from Pushbullet so I'm still getting used to Join. But I understand every push goes into clipboard, so yeah I guess I'm sending clipboards.
I would like to have them delivered because I use Join/Pushbullet not only for sharing clipboard and texting through my PC, but also as a centralized notepad where I place random ideas, ToDo's, and also interesting links so I can check them out later. For example if I'm in a car ride and I don't have time to watch a video someone linked me, I will 'push' it to my Chrome so I it shows up when I get home.
Is there any other way that I can reliably send pushes/clipboards that are guaranteed to be delivered? Am I doing it the way I shouldn't?
Sorry for the delay. Can you please try this:
-close chrome on PC
- on your phone open a browser and share a link to your PC
- then open another page and share that too
- do that a third time
- open Chrome on PC
Do all 3 pages open correctly? This is the situation I had in mind when developing this :)
I tried it with 4 pages, only 3 opened, like you said.
But when checking the device's push history, only one of them is there.
Ok, I'll try to figure out why that is. Thanks
Ok, I've now made a change with this version: https://www.dropbox.com/s/bfjh0oaeri6cqfm/Join.apk?dl=1
This should store your Chrome pushes for the next time you open chrome on your PC and open them there if not opened yet.
Make sure you're using at least version 1.7.2 of the chrome extension to make it work.
Can anyone please try it and let me know how it works? :) Thanks in advance
So it seems to work. They do however seem to lose order. Also as you can see Chrome 59 now uses native notifications for MacOS
https://f001.backblazeb2.com/file/DropshareNew/Screen%20Shot%202017-06-06%20at%209.22.41%20AM.png
Thank you Tom! Just pushed a new update to fix the sorting :)
I now mostly push from Chrome (Chromebook) to Chrome (Windows). Will this update help there, too? (I won't have time to test today, but hopefully tomorrow.)
In my limited testing it did not end up working from Chrome to Chrome. One issue is this kills encryption.
Can confirm that it works for me. Sent some pushes from mobile to Chrome while my PC was shutdown and they greeted me upon starting my PC and Chrome. Cool!
Ok, added support from chrome to chrome stored pushes! :)
Let me know if it works now! Thanks!
Any news on this? I'm losing pushes on both Chrome and Android. I have a script that pushes links overnight through the API... none of the pushes are delivered when I wake up :(
Not yet, sorry. I still have to find the best way to implement this.
Yes, the API goes through Appspot, but the appspot server is not able to write to your push history file on Google Drive directly. Only clients can do that.. Hence the dilema :)
What's the underlying push technology Join actually utilizes?
Is it FCM? FCM claims to have store-and-forward built-in: https://firebase.google.com/docs/cloud-messaging/concept-options#lifetime
Yeah, but for some reason it doesn't work with the chrome extension :(
Google really seems to spread itself a bit too thin...
Now that I'm starting to use my Chromebook more and more, I'm finding I can't use Pushbullet anymore since they refused to treat a Chrome instance as an individual device.
So now I'm back to having to mail myself links from the office. Ughh..
Do you see any hope at the end of this tunnel?
Ingo, would it help if just the pushes from other devices would have this behaviour and Join API pushes wouldn't?
Absolutely, I use it mainly like I used to use PB, just as a way to push URLs to the correct device. I read my newsfeeds and emails on the bus and send the ones I want to investigate either to my office or my home.
Instead of the receiver of a "push" writing to the new history feature file, the sender should write to the history.
Then a client that comes online can easily see what it missed during the time it was turned off or just offline and still receive those pushes. Voila! Guaranteed delivery!
The problem is when pushes are sent through the API and not a client app. In that case there's no one to write the push to the push history.
Ah, I was under the impression that the API talked to an Appspot service, it would, since it's logged in as me, have access to my Gdrive. I guess I need to revisit my understanding of Appspot, it seems to be "spotty". (See what I did there? ;-) )
That should already be happening. What device doesn't receive pushes when it's turned on and what kind of pushes are those? Thanks
For Chrome devices at least, this is not happening. If I push a link to a Chrome browser that is not running, I would expect the link to open when I next launch. It is silently lost.
I'll look into that not happening with Chrome again. Last time I checked the messages were being lost by google somehow. Thanks
Definitely silently lost on my Asus Flipbook
Then an option to choose if the push should be ephemeral or have a guaranteed delivery can be interesting.
Some of my pushes via the tasker plugin are only useful if they are received a few seconds after they are sent, so I don't want to see them if I turn on a device a few hours later.
Some others have to be delivered even if I turn on a device hours later.
I learned a new word lol.
There should be two options then:
• Ephemeral
• Eternal
I think this should be implemented like it works in mqtt qos 2
And how would that be exactly?
