When coins are received and you are on the receive screen, a more visible notification would be good

[GoogleCodeExporter]

The current notification method makes a ton of sense for when you receive coins 
without expecting it. But if you're currently sitting on the receive coins 
screen, you're probably watching it to see when the coins turn up. A tiny icon 
in the top notification bar is easy to miss. On this screen, something more 
visible would be good.

I suggest something fun - maybe an animation of a coin that "lands" on the page 
as if it had been dropped onto the screen from a height and makes the screen 
wobble a bit. I think in ICS+ these sorts of animations became a lot easier to 
do.

Original issue reported on code.google.com by mh.in.en...@gmail.com on 16 Jul 2012 at 9:37

[GoogleCodeExporter]

Generally I like the idea. However, I fear that the user is tricked into 
thinking that he just received the transaction he was requesting. It could be 
completely unrelated, and AFAIK there is no way to relate really (other than 
the amount, which IMHO is not sufficient).

Original comment by andreas....@gmail.com on 16 Jul 2012 at 12:34

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Ok, obviously of course you could use the address for relating. However, 
currently Bitcoin Wallet works with always the same address for most users. I 
think for the "one address per payment request" to really take off, stuff like 
deterministic (brain) wallets need to be adopted first, both by the app and its 
users. And before even that, we need reliable backups and restore. And for 
that, we need blockchain rewind...

Original comment by andreas....@gmail.com on 16 Jul 2012 at 2:02

[GoogleCodeExporter]

Given how mobile wallets are presently used, I really doubt there will be many 
times transactions coming in simultaneously. And this is only a change in how 
the notification is rendered. You still have the potential confusion with the 
notification-bar icon.

Re: backups. As I've said before, you don't need blockchain rewind to do 
backups. Restoring from backup should be a very rare operation, so you can just 
delete the block chain and let it sync with getheaders from the genesis block, 
or re-copy over your built in chain. I do this all the time with my own 
wallets. Rewinding the block chain to the earliest key time is just an 
optimization, and one I'm not even sure matters much.

Original comment by mh.in.en...@gmail.com on 17 Jul 2012 at 7:35

[GoogleCodeExporter]

What sense do backups make without restore? So yes, if I say backup I actually 
mean both backup and restore.

Can you post your code example of how you implement restore? Specifically, how 
do you clear out all the caches and make sure peers do not continue to run in 
parallel while you're copying?

Original comment by andreas....@gmail.com on 17 Jul 2012 at 8:07

[GoogleCodeExporter]

I know you have a setup currently where you assume every object is live all the 
time, but that's not a requirement. Android apps can have modes, I use apps 
that do this kind of thing all the time. If you want to do a restore from 
backup, you can stop the PeerGroup, delete the block chain file, clear the 
wallet, re-build the objects and start them back up again.

I'm really not convinced that having complicated support in bitcoinj for this 
is better than you just implement restore on your end.

Original comment by mh.in.en...@gmail.com on 17 Jul 2012 at 10:04

[GoogleCodeExporter]

Bear in mind that PeerGroup.stop() does not give and guarantees about when 
actual block processing will stop. I have seen delays of up to 5 minutes, and 
in some special (probably error) states even inifite.

So your approach is (at least currently) not possible.

Original comment by andreas....@gmail.com on 18 Jul 2012 at 9:24

[GoogleCodeExporter]

Right, that's a bug. I think the switch to using Netty may have improved this 
situation dramatically, but I haven't tested it.

Original comment by mh.in.en...@gmail.com on 18 Jul 2012 at 9:25

[GoogleCodeExporter]

Back to the topic: I have thought a bit more about how give nicer feedback to 
the requester/merchant.

What I plan to do soon is display a list of payments that was received to the 
requesting address. This will probably include transactions that were received 
before the request, but in this case I'll visualize this fact.

The list of payments will sit right of the request form, so on tablets both 
will be visible. On phones, the view pager will be used to page between the 
form and the list. I'll experiment with automatically paging to the list as 
soon as the first payment is received in order to make the list more 
discoverable to the user.

As soon as the requested balance is reached (probably through multiple 
payments), it will be indicated clearly.

The whole functionality probably only makes sense in a "new key per payment" 
mode, so perhaps if I will add such switch in future it will only be accessible 
in this mode.

Also, I'm thinking about locking the form as soon as the request has been sent. 
(Because it's not possible to detect this condition in the case of scanning QR 
codes, the event of the first received payment or an incoming BT connection 
would serve as a substitute.) The idea is that you don't accidently change the 
request afterwards. If you want to issue a new request (without having to 
re-enter "request bitcoins"), there will be a "new" button in the action bar.

Original comment by andreas....@gmail.com on 18 Jul 2012 at 12:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

That sounds like a pretty good solution.

Original comment by mh.in.en...@gmail.com on 18 Jul 2012 at 1:46