I would like guides and directions of where to start, resources I can use to understand the topic better. The deposit and withdraw system would be very similar to crypto exchanges where the user will have their own addresses to deposit different cryptos and can withdraw them.
Have you tried the BSV library. Albeit for safer non custodial wallets. But this does not mean to say you cannot integrate that with cloud apps.
It's done superbly by Handcash already.
There's excellent support docs and tutorials using live main and test net addresses at Satolearn and BSV Academy.
I am trying to find a solid, scalable way of integrating stripe into a react native (managed workflow with expo) app for android & iOS.
There are several options. E.g.:
tipsi/stripe
expo/payments
Directly communicating with the stripe API (e.g. as described in this blog post)
I would like to go with option 3 as it's the one with the fewest overhead and most flexible (you don't need to eject expo, etc.). Now my question is, are there compliance/ security issues when directly calling the stripe API in a production mobile app? (Given the fact that payments need to follow a lot of restrictions and are a highly sensitive topic)
Thanks a lot
I am trying to develop an application on class attendance using fingerprint. Through rigorous research, I found out that I can use 'flexcodesdk' for my Vb.net program.
But the issue is that for every fingerprint scanner (Digitalpersona) there is needed to register it on flexcodesdk site to get series of API keys. What am I going to do about this issue because once I change the fingerprint scanner of similar product, it will complain of registration invalid.
Many developer develop applications an any body can use different scanner regardless of the serial number.
Help me out gurus in the house.
It appears that their FAQ states that each license is tied to a specific device.
How many devices that can be used in one FlexCode SDK license ?
Only the device that you submitted the registration number.
This means that each new device needs to be registered into their system in order to provide you with a new license for their SDK.
This seems quite a restricting model.
Perhaps you might want to consider the free and open source c# implementation at https://www.codeproject.com/Articles/97590/A-Framework-in-C-for-Fingerprint-Verification
I have successfully created multiple applications using this framework.
I am developing a device firmware based on an LPC17XX+FreeRTOS. My development environment is Eclipse + GCC, codes are in C. The requirement of the end product is:
A "base firmware" running RTOS and performing some periodic task (eg. perform health check).
The base firmware needs to support an API which will have some functions for data manipulation/delay/timing and some functions for using the device ports and I/O.
The user can build their own app using this API.
The user app needs to reside in an empty space of the flash. (It will be sent to the device via Serial port and I plan to use IAP to save it on flash)
I want to start the app as a new task from the "base firmware".
Step 1 and 3 are fairly easy to implement. I am not sure what is the best way to implement 2,3 and 4. So far I've looked at Dynamic linking, jump tables, overlays etc and I am kind of lost. Can someone give me an overview of proper implementation steps?
Some related questions:
Any other way to develop firmware for a product which provide API based App/module development and loading?
What do I need to provide to the user for using the API? Will my API source code be open?
I am open to any ideas, thanks :)
Bloomberg Open API announced recently - is it just the Bloomberg SDK which had been (limitedly) exposed to public for quite a while?
My understanding is that Bloomberg SDK is possible to use only on the machine with a Bloomberg Terminal installed, but the recently announced Open API (which is syntactically the same) will be possible to use from any machine.
Is that correct? Are there any restrictions on the new API (say, delayed responses etc)? Just cannot believe they're giving away for free something that costed money - any clarifications are welcome!
EDIT: The above was probably not clear, so to rephrase:
I wonder if the newly announced Open API is syntactically the Bloomberg SDK API (or how they call it?) which has been available for years already
assuming there are restrictions on using Open API on any machine (comparing to using SDK from a machine with Bloomberg Terminal installed) - I wonder if those restrictions are specified in detail in some official Bloomberg doc.
I can myself guess on both questions, but I thought I'd rather ask :)
Since the data is not free, you can use this Bloomberg API Emulator (disclaimer: it's my project) to learn how to send requests and make subscriptions. This emulator looks and acts just like the real Bloomberg API, although it doesn't return real data. In my time developing applications that use the Bloomberg API, I rarely care about the actual data that I'm handling; I care about how to retrieve data.
If you want to learn how to use the Bloomberg API give it a try. If you want to test out your code without an account, use this. A Bloomberg account costs about $2,000 a month, so you can save a lot with this project.
The emulator now supports Java and C++ in addition to C#.
C#, C++, and Java:
Intraday Tick Requests
Intraday Bar Requests
Reference Data Requests
Historical Data Requests
Market Data Subscriptions
Edit: Updated Project link, moved to github
The API's will provide full access to LIVE data, and developers can thus provide applications and develop against the API without paying licencing fees. Consumers will pay for any data received from the apps provided by third party developers, and so BB will grow their audience and revenue in that way.
NOTE: Bloomberg is offering this programming interface (BLPAPI) under a free-use license. This license does not include nor provide access to any Bloomberg data or content.
Source: http://www.openbloomberg.com/open-api/
This API has been available for a long time and enables to get access to market data (including live) if you are running a Bloomberg Terminal or have access to a Bloomberg Server, which is chargeable.
The only difference is that the API (not its code) has been open sourced, so it can now be used as a dependency in an open source project for example, without any copyrights issues, which was not the case before.
I don't think so. The API's will provide access to delayed quotes, there is no way that real time data or tick data, will be provided for free.