I have an ExpertAdvisor ( EA ), named Hedging Recovery EA, it works correctly on my demo MetaTrader account, now I'm about to create an account with a 5 USD deposit and about to deposit +1000 USD on it, but I'm not sure, if the EA will work, because I have heared that a Demo EA works only on a Demo MetaTrader account.
If it is true, how can I make it work on a live-account?
This is the executable format of the said EA :
http://www.mediafire.com/download/cezoct5m7cgqngm/Hedging+Recovery.ex4
FACT: You're trying to use a commercial EA without paying for the fee. This is unethical.
ANSWER: Putting ethics aside, the solution to your problem is to use a CopyTrade software. Basically, run the EA on a demo-account (the EA allows for it), then copy-trade it into a real-account.
You can use a CopyTrade, there are some that are free, but mostly are commercial too.
If you are really cheap, you can open a Signal account in www. MQL5. com (remove the space), set it to free subscription, then subscribe your real account to it.
On The Side (not related to the answer):
a. If you really believe in an EA/strategy but cannot afford $99 for it, you should not be trading.
b. These type of strategy works well in a fierce-trend movement, but your account will blow in a ranging-market. Don't set it to auto-trade for you. It will blow after a while.
Facts:
EA authors publish, that:
- the code contains a remote-license validation protection
- the code shall never be used under other circumstances but only on relatively small account - with equity < $10000 and > $4000
- trading license costs $99, or $199 with code-adaptations, other options available
Next steps: How to make it work on live-account?
1 ) Attempt to make your operations compatible with the said equity advice.
2 ) Choose a license type that best meets your expectations3 ) buy the suitable license
Related
Is it is possible to make users pay for digital points so that they can use them for real-world services outside of the app?
Take for example 'Uber', assuming we have the same model, can users purchase 'bundles' of 'points' and then use these points to order a taxi service?
Will this be allowed on the app store?
This is basically the "digital wallet" problem. All kinds of issues exist, from security, to convincing vendors to accept it, to convincing customers to trust and use it, to figuring out how you're going to take a fair profit out of it..
Frankly, Apple has claimed to be working in this space themselves, as are the credit card companies. Given your question, I have to assume you have nowhere near the resources they can afford to spend on this effort, and their efforts are still vaporware.
If you really have a way to make this work, I suspect you could sell it to one of them for a few million. If you just have the idea... well, it's premature to try to guess whether Apple would try to lock you out or not, and only they can answer that question in any case.
I am working on a Mobile POS integration with Verifone E315. I am relatively new to this payment processing industry, so i don't know the nuances and how things work. Following are my questions -
I would like to know if Verifone E315 is just a card reader or will also take care of payment processing.
Also, can we integrate other payment gateways by just using the Verifone E315 as a card reader?
Is there any sample code available to read card data with Verifone E315?
How does Apple Pay integration works with Verifone E315?
Any help would appreciated.
payworks offers a SDK to do transactions with the E315.
Disclosure: I am a software engineer at payworks
I have worked with all sorts of VeriFone terminals from Tranz/Zon to Omni 3200, to Verix/VerixV and eVo (3740/3750, 3730/510, 570, and 520). Unfortunately, I am not familiar with the E315, but I suspect my answer will apply to it as much as it would to the other platforms (you may want to follow up with a VeriFone rep to make sure--I'm sure he/she would be very happy to discuss it with you if there is a chance you may be buying some more of their hardware).
All VeriFone terminals I have ever worked with are just empty hardware--you have to provide all the software in order to make it work. There are various companies (and I think VeriFone is one of them) that have already developed software for the terminals that will handle credit card processing and/or check processing. I have never done this, but I've seen them in use in in many stores. Alternately, you can write your own program which will include all user prompts, all communication to a remote server that will do the actual processing, all the code for printing receipts, etc. (this is what I do). Obviously, this is a lot more work, but it gives you all the flexibility you could want.
That really depends on what you are trying to do, but probably. We actually do something like this--we read card data on the terminal and then send that card data to a server which in turn connects with one of a variety of other platforms we have integrated with and it all works swimmingly.
Again, I'm not familiar with the E315 or its platform, but the SDKs for the other models have all come with lots of documentation including, in some cases, sample code here and there. Again, contact a VeriFone rep and see what you need to do to get access to their developer's web site, "DevNet".
Sorry--I'm afraid I don't know anything about Apple Pay.
I'm going to deploy new paid app to appstore. This app will connect to our server and download some data (pretty big sometimes).
I'd like to know, is there any way I can check (on server side), that request is going from app, which was really paid (not stolen).
I know that anybody can buy app once and then distribute it (and guys with jailbreaked phones/pads can install it easily). It may cause extra traffic from our servers, and we want to protect us from it.
Or may be I can somehow figure out, that request comes from one sold copy of app? In this case, I can restrict numbers of downloads from one copy, so if it will be widely distributed, it just stops works one day.
Any ideas?
I am copying this verbatim from an email I sent to the cocoa-dev mailing list a while back to someone who had your concerns. The numbers have probably changed, but my rationale still applies as to why I think it's a waste of time to even think about this sort of stuff.
Setting aside all the technical issues, do you have evidence that
jailbreak piracy is a large enough problem to justify you doing all this?
For one, while I don't have a percentage I'm quite certain that it is a
minority of phones that are jailbroken. I run with a pretty tech savvy
crowd and I know only one person who has jailbroken their phone, and I
am fairly confident that techies are more likely to go through the
trouble. (How many average users have the faintest idea of what it
means to "jailbreak" a device?)
Jailbreaking is probably more prevalent in countries and cultures with
less of a tradition of paying for software. But this leads to the
second point...
From your standpoint you (presumably) really care about converting
would-be software pirates into paying customers. If they can't use
your app on a jailbroken device yet don't buy it legitimately, you
haven't accomplished anything economically worthwhile. In fact, you may
be worse off because you lose the (admittedly small) possibility that
the would-be pirate will show off your app to others who might in turn
become paying customers.
So, your calculus ought to be something like:
(# users with compatible devices) * (% with jailbroken devices) * (%
interested in your app) * (% unable or unwilling to circumvent your
protection) * (% who will purchase your app when confronted with copy
protection) * ($ price per sale) > (increase in legitimate sales that
could be obtained by devoting development resources to product
enhancement, marketing, support, etc.)
Let's suppose that 250M compatible devices have been sold, with 150M
distinct users (assuming that there are many people who have replaced
devices or own iPad with an iPhone, etc.) Suppose 10% are jailbroken,
which is what some cursory Googling turns up. That gives us 15M
candidate users.
Now, unless you are writing Angry Birds, it seems unlikely that you will
appeal to any more than 1% of the user base. That leaves 150K users.
Maybe 80% are unwilling to circumvent your copy protection, leaving 120K
users. Now the kicker: how many are then going to want to actually buy
the app? Maybe 5%? That puts you at 6000 users.
So with these admittedly crude guesstimates, if you could gain even 6000
users (out of the 135M non-jailbroken user base postulated above) by
devoting your time and energy to anything else, you'd come out ahead.
Well there are many tries to detect, if a device is jailbroken. But most of them can be tricked out again. So there is no SAFE method of detecting a jailbroken device. But just search for "detect jailbreak".
Than you could send your result to your server (together with the data request) and decide, what to do. But think about the effort, as said by Conrad Shultz.
Anyway you can track, how many apps are sold and how many server requests there are. So you will have youre private statistic, how many copies of your app are stolen. You can upload an update for your app anytime, if it really will be a big problem in your case.
Testing in-App Purchases seems fairly straightforward but I want to release my app globally. If I read the dev guide correctly, it says that I can only have 1 test account per territory. So am I stuck making over 150 test accounts? There has to be a better way!
I would agree with Kheldar. Is there a specific reason that you need to test for all your territories? Personally I would test my app for one territory and assume it works the same for all.
They just "suggest" that because it's a good idea to make sure all the currency values are tested for everywhere you want to release it at plus any sort of localization.
Really big companies are the only ones who can truly test that way - it costs a lot of resources to validate every country...
By not doing it you will be fine, plenty of indie apps get released with only enough testing to make sure the app runs with the normal framerate and you can do each of the features without crashing and these apps have done very well in downloads and sells (even with the inevitable 'issue' that pops up here and there). Leave a support e-mail/contact and makes sure to check your reviews for anything major you need to address and you will be good to go.
Just test with your major area or major areas (ie: Your a German living in America and want to make sure your German and America versions are top notch so test the '2' versions and release everywhere!) and handle anything else as/if it comes by.
This is a very general question. I'm asking because I want to know in advance if it's worth the time and money to jump into this market?
Apple's iOS developer program costs $99/year. MonoTouch looks good but costs $399/year (I feel comfortable with .NET). That's $500/year. So for an app priced at $1 needs to sell 500+ copies per year? How likely is it to achieve this number? How about free app with ads? Is there any extra cost?
Personally, I feel that the iPhone ship has sailed, for the most part. While we did get some decent sales from our "iAmbigram" app for the first 3 months or so back in early 2009, the sheer onslaught of apps in the app store make it all but impossible to get located (even if you have a pretty darn good app).
We spent about $3.5k to develop the app, and have basically broken even over the course of 2 years. It wasn't the windfall we were hoping for, but I understand that few apps are. We have a second app in the store which was pretty much a total loss (at $.99, even).
The problem, as I see it, is discoverability. Unless you have a killer app, people will not know about it, and you will suffer in obscurity forever. At least on the web, you can do some basic SEO and rank high on Google and make some $$ that way, but on the iPhone... there is no similar mechanism.
Anyway, I wanted to share our case study. Believe it or not, it's not easy to make back even a small $500 on iPhone apps these days (which was certainly NOT the case in 07 and 08).