Obedear --> When using the NEAR - NFT Tutorial repo, and your using that contract to mint a collection, how would u keep track of incrementing NFTs being minted?
My thought is you could request the current token ID and metadata from the backend for every mint, would that work?
Benji | NEAR --> I’m confused by your question could you elaborate
Obedear --> I have deployed the NFT tutorial contract and I want users to be able to go into my website and mint an NFT
Everytime a user mints the dApp feeds the contract (NFT 1, Img url: 1, User A).
then when another mints its NFT 2 and img url 2, User B.
My thought is I use a database to store the incrementing Number of what NFT needs to be minted next. Everytime someone mints the dApp sends a request to the backend which hands back what number its up to.
Another option (which I think is how solana does it), is store this incrementing number in the contract and the dApp has the ability to read this value so it knows what token # and img url to give NFT contract next (on solana its stored in an account). This second option is a preferred method tbh.
Obedear --> Essentially can I use a contract to store a number and have a dApp read that number without using a transaction?
Benji | NEAR --> why do you need incrementing token IDs?
Obedear --> for an NFT collection
Benji | NEAR --> you can easily do this within the contract then.
Benji | NEAR --> take the requirement to pass a token ID out
Benji | NEAR --> and then just keep an incrementing number in the contract
Benji | NEAR --> and make that your ID
Obedear --> but then how do I know which image URL to pass it?
Benji | NEAR --> you can still pass in metadata just don’t pass in token ID
Obedear --> All NFTs will have a different metadata though, and I need to keep track of which ones have been passed in and which havnt
Obedear --> Is there a way I can read this incrementing number from the contract in a dApp?
Benji | NEAR --> yea sure just add a view method that returns the incrementing number
Obedear --> where does the contract store this incrementing number?
Benji | NEAR --> you’ll have to store it in the contract struct
Benji | NEAR --> so in state
Obedear --> like in here?
Benji | NEAR --> yes. I would highly recommend going through the tutorial before starting ur contract so you understand how everything works
Obedear --> will do, just asking some questions before I get into it
Obedear --> Can you call this method without paying gas fees of any kind?
Obedear --> or would it have to be a transaction?
Benji | NEAR --> it’s a view function so yes
Benji | NEAR --> you can call it for free
Obedear --> would an example of that be the nft_supply_for_owner function?
Benji | NEAR --> yes
Obedear --> okay sweet, Im going to go through this tutorial before asking anymore questions for ur sanity’s sake!
Thanks for the help man, I am super stoked to build on some stuff on NEAR. Im coming over from SOL so I am familiar with rust
Benji | NEAR --> awesome! we’re glad to have u 🙂
How to build native mobile apps on NEAR
🛠 │ dev-support
status - Unresolved
padiyar --> Hey everyone, been wanting to explore how the devs can build native mobile apps on near. How to make the frontend library work etc… If there has already been any discussion on this, could someone point me to it?
bucanero --> Native mobile apps built for iOS / Android? I’m not sure if we have such examples, as those would probably require a native library for iOS or Android
How to fetch NFT details using method 'nft_create_type'
nrmmyth --> Is it possible for an contract to create accounts outside it’s hierarchy? For example a contract A.near to create an account B.near or all the accounts have to follow *.A.near path. Thanks!
bucanero --> No, I think the contract can only create sub-accounts on it’s own hierarchy. Perhaps you could have another contract on the “A.near” account and do some cross-contract call, if you really want to create subaccounts on a different near account.
nrmmyth --> "No, I think the contract can only create sub-accounts on it’s own hierarchy."
Could you confirm this? Either way I just want to have a clear messaging towards our users if this is a limitation of network or not.
"Perhaps you could have another contract on the “A.near” account and do some cross-contract call, if you really want to create subaccounts on a different near account."
In your example how would you achieve that A.near creates a C.B.near account?
Part of the infrastructure layer is a self-written scanner based on block parsing.
It is needed to catch the events generated by the contract, process and call the necessary contract functions in another network.
A general description of the scanner’s operation using the example of ether-like networks: we connect to an RPC provider and parse each block for the existence of a contract event.
That is, we ask the scanner to search for a specific event at the address of the contract, which it (the scanner) will look for in each block. When a specific event is found, the corresponding handler is launched.
We are looking for a solution for Near scanning.
Is there already something similar in Near? Maybe someone is ready to help us with this task?
bucanero --> TheGraph recently added support for NEAR. You might want to check it out
Dorian | NEAR --> I made a quick tutorial that breaks down the setup of the Graphs indexer intergeneration into NEAR if you want to check it out.
Zin --> Hi! where can I watch this tutorial?? Please!!
RealHum --> That’s would be great, thanks
Dorian | NEAR --> <@!RealHum> <@!Zin> Here is the writeup I just made! Would actually love your feedback on it if you guys want to go through it. Def let me know if you have questions
I don’t have a video for this yet but if that’s something that interests you I can make one.
lilses --> is near-sdk-sim still recommended for testing contracts?
lilses --> i’d imagine so because how else can we get coverage?
Dorian | NEAR --> let me check for you, I think we have something else but I want to make sure what I’m thinking about is for the proper use case
austinabell --> We are transitioning to using workspaces for testing as it is a quicker and more accurate simulation. We haven’t transitioned examples or deprecated sim tests yet, but they will be in the future.