Class NativeBlockChainListener
- java.lang.Object
-
- org.bitcoinj.jni.NativeBlockChainListener
-
- All Implemented Interfaces:
NewBestBlockListener
,ReorganizeListener
,TransactionReceivedInBlockListener
public class NativeBlockChainListener extends java.lang.Object implements NewBestBlockListener, ReorganizeListener, TransactionReceivedInBlockListener
An event listener that relays events to a native C++ object. A pointer to that object is stored in this class using JNI on the native side, thus several instances of this can point to different actual native implementations.
-
-
Field Summary
Fields Modifier and Type Field Description long
ptr
-
Constructor Summary
Constructors Constructor Description NativeBlockChainListener()
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description void
notifyNewBestBlock(StoredBlock block)
Called when a new block on the best chain is seen, after relevant transactions are extracted and sent to us via eitherTransactionReceivedInBlockListener.receiveFromBlock(Transaction, StoredBlock, AbstractBlockChain.NewBlockType, int)
orTransactionReceivedInBlockListener.notifyTransactionIsInBlock(Sha256Hash, StoredBlock, AbstractBlockChain.NewBlockType, int)
.boolean
notifyTransactionIsInBlock(Sha256Hash txHash, StoredBlock block, AbstractBlockChain.NewBlockType blockType, int relativityOffset)
Called by theBlockChain
when we receive a newFilteredBlock
that contains the given transaction hash in its merkle tree.void
receiveFromBlock(Transaction tx, StoredBlock block, AbstractBlockChain.NewBlockType blockType, int relativityOffset)
Called by theBlockChain
when we receive a new block that contains a relevant transaction.void
reorganize(StoredBlock splitPoint, java.util.List<StoredBlock> oldBlocks, java.util.List<StoredBlock> newBlocks)
Called by theBlockChain
when the best chain (representing total work done) has changed.
-
-
-
Method Detail
-
notifyNewBestBlock
public void notifyNewBestBlock(StoredBlock block) throws VerificationException
Description copied from interface:NewBestBlockListener
Called when a new block on the best chain is seen, after relevant transactions are extracted and sent to us via eitherTransactionReceivedInBlockListener.receiveFromBlock(Transaction, StoredBlock, AbstractBlockChain.NewBlockType, int)
orTransactionReceivedInBlockListener.notifyTransactionIsInBlock(Sha256Hash, StoredBlock, AbstractBlockChain.NewBlockType, int)
. If this block is causing a re-organise to a new chain, this method is NOT called even though the block may be the new best block: your reorganize implementation is expected to do whatever would normally be done do for a new best block in this case.- Specified by:
notifyNewBestBlock
in interfaceNewBestBlockListener
- Throws:
VerificationException
-
reorganize
public void reorganize(StoredBlock splitPoint, java.util.List<StoredBlock> oldBlocks, java.util.List<StoredBlock> newBlocks) throws VerificationException
Description copied from interface:ReorganizeListener
Called by theBlockChain
when the best chain (representing total work done) has changed. In this case, we need to go through our transactions and find out if any have become invalid. It's possible for our balance to go down in this case: money we thought we had can suddenly vanish if the rest of the network agrees it should be so.The oldBlocks/newBlocks lists are ordered height-wise from top first to bottom last (i.e. newest blocks first).
- Specified by:
reorganize
in interfaceReorganizeListener
- Throws:
VerificationException
-
receiveFromBlock
public void receiveFromBlock(Transaction tx, StoredBlock block, AbstractBlockChain.NewBlockType blockType, int relativityOffset) throws VerificationException
Description copied from interface:TransactionReceivedInBlockListener
Called by the
BlockChain
when we receive a new block that contains a relevant transaction.A transaction may be received multiple times if is included into blocks in parallel chains. The blockType parameter describes whether the containing block is on the main/best chain or whether it's on a presently inactive side chain.
The relativityOffset parameter is an arbitrary number used to establish an ordering between transactions within the same block. In the case where full blocks are being downloaded, it is simply the index of the transaction within that block. When Bloom filtering is in use, we don't find out the exact offset into a block that a transaction occurred at, so the relativity count is not reflective of anything in an absolute sense but rather exists only to order the transaction relative to the others.
- Specified by:
receiveFromBlock
in interfaceTransactionReceivedInBlockListener
- Throws:
VerificationException
-
notifyTransactionIsInBlock
public boolean notifyTransactionIsInBlock(Sha256Hash txHash, StoredBlock block, AbstractBlockChain.NewBlockType blockType, int relativityOffset) throws VerificationException
Description copied from interface:TransactionReceivedInBlockListener
Called by the
BlockChain
when we receive a newFilteredBlock
that contains the given transaction hash in its merkle tree.A transaction may be received multiple times if is included into blocks in parallel chains. The blockType parameter describes whether the containing block is on the main/best chain or whether it's on a presently inactive side chain.
The relativityOffset parameter in this case is an arbitrary (meaningless) number, that is useful only when compared to the relativity count of another transaction received inside the same block. It is used to establish an ordering of transactions relative to one another.
This method should return false if the given tx hash isn't known about, e.g. because the the transaction was a Bloom false positive. If it was known about and stored, it should return true. The caller may need to know this to calculate the effective FP rate.
- Specified by:
notifyTransactionIsInBlock
in interfaceTransactionReceivedInBlockListener
- Returns:
- whether the transaction is known about i.e. was considered relevant previously.
- Throws:
VerificationException
-
-


--- layout: post title: 'All Your Base Belong to Amp''d' date: 2005-10-09 00:00:00 categories: business digital-media mobile ---
All Your Base Belong to Amp'd: "Its target market is 18- to 35-year-olds, and the stuff it's got lined up should be wide and deep enough to satisfy the whole range: lots of video (streaming and download), music, tons of games and so on. The phone ships as a blank slate, essentially, and users set it up via the Amp'd Web site to make it appear exactly as they want."
I first heard about Amp'D at BREW2005 this year and they sound a bit different from your run-of-the-mill carriers... but are founded by a guy who's kicked off umpteen MVNOs. One to watch.


{% extends "base.html" %} {% block body_content %} {% include "_logout.html" %}
Tell us how you rate yourself against the Civil Service's four key capabilities. A capability is a mixture of skills and experience. Not all may apply to you; indeed none may apply yet.
The Civil Service needs to be ready for the challenges of the future. Our staff already have skills in operational delivery, policy etc. We also need new skills to remain fit for purpose in 2020. The Civil Service capability plan identified four areas that are essential if we're going to be ready to deliver in the future.
We want to know whether you have skills in these new priority capability areas. Tell us your level - as you understand it - using the sliders below. If you're not sure, there is guidance below each one. You can also discuss them with your manager.
You and your manager may also want to think about these areas when considering any development objectives for the year. You can update the levels any time you feel you have made progress.


Please open this page in multiple tabs/windows. (not that many tabs though, because browsers have a maximum number of simultaneous persistent connections per server, which is somewhere between 4-8 depending on the browser.)
All tabs/windows should update the number of connected clients, in realtime.