I have been playing around with the currency converter web service offered by http://webservicex.net as a way of learning how to interact with a web service from an iPhone application and I have managed to get the currency converter working perfectly.
I have since expanded my application to include other features to make it something a little 'different' from what is currently available on the App Store.
The question that I have is if I release an app on the App Store and that is ad-supported am I allowed to use this web service that someone has obviously put time and effort into making? Up until a month ago I did not even know what a web service was or how it existed so I am not sure if there is any etiquette (eg, give them a mention in the About page of your app) or if these things are generally out there and free to use?
I have tried contacting Webservice X via email but every time I get a bouceback because their mailbox is full, which has helped get me closer to an answer. Has anyone else used their services or know of the standard allowed use of someone elses web service in an ad-supported application?
Thanks guys!
Using their web-service is not going to get you rejected. That being said, relying on someone else's equipment (of which you have no control and are not paying for usage) is not a good idea for a production app. I would do some research into finding a service that you feel is going to be more reliable or can pay (a minimal amount) to use.
The other piece of advice I would give is to build the application so that it gets the data from your own web-service and let all the base data come from you. In other words, get your own web-site (from as little as $7 a month from GoDaddy or other services), and do the currency lookups there. Build your server-side processes to be easy to swap from one service to another and that way if for some reason you lose access to the currency converter service you have been using, it is a quick amount of work to switch to a different one without having to release a whole new version of the application (and wait 7+ days for the app review process).
In other words, your web-service you build supplies all the data for the iOS app and you get the currency data on your web-server.
That is how I would do it to make sure it is the most reliable and easiest to change without affecting the installed iOS app.
Related
I'm using swift — and the app needs to send a photo and matching text (that a user submits) to a server so that I can download the photo/text.
Would an existing FTP server that I have setup for my website be possible for this application? Or would it make more sense to do something with a web portal?
During my research, I'm finding options like Backendless, Alamofire, Gold Racoon, and various others. They seem like overkill for the simple task I'm looking to accomplish. Is there some minimal service out there that can automate my simple need? If not, which of these options would you recommend for my situation?
Ideally the setup would be free, but I'd be willing to spend up to $100 or $10/month if the service fits.
I'm new to app development so I'm feeling overwhelmed with the options and not sure how to begin researching. I hope beginner questions aren't frowned upon here — I would really appreciate any advise on what I should begin learning to achieve my goal of sending a photo+text from an iOS app to a place where I can access them.
If there are other questions I should be asking to achieve this, please let me know.
For your case there are two main routes to consider
1. BYOS (Bring Your Own Server)
With this option, you are responsible for creating and maintenance of your own server.
Now you can use various services such as Digital Ocean and Amazon for this.
On top of this, you would be responsible for creating your own database and maintaining it as well. Plus, you would need to write server side code along with client side code (the app) in order to instantiate communication between the two.
The advantage of this is that you virtually have control of everything but I think it is pretty clear how painful this task is.
2: BAS (Backend As a Service) Highly recommended
With this route, you simply have to write the app and let another service handle the server side of things. One of the most common ones is Firebase. Most folks including startups go down this route.
There are a bunch of other services out there.
Two Cents:
Whatever option or service you decide to use, I would recommend you make sure that:
a. The service has a good track record.
You do not want something that might end up getting shutdown in the next couple months. I know it is hard to predict this but certain initial guesses/probabilities can be made.
b. Make sure its community is vibrant.
The last thing you as a newbie wants is to be stuck and have no one to help you. Research around and see the different questions people ask and whether or not answers exist.
I currently have a few apps that I provide to clients by setting them up on their own website. The app uses their own SQL database to record any transactions.
Recently, the number of customers I supply the app to has increased, leading to a higher maintenance work load as each installation must be managed separately.
I'm ready to move to the next level and want to host the app in a single cloud based environment so that I only have to maintain one instance. I would then provide access to that app to each client site, for example embed it in an iframe or perhaps deliver it via a sub-domain. I am not sure about where the DB would sit?
However, this is new territory for me and I'm not sure where to begin. The app is very small and quite simple. I've read a lot of stuff about SAAS but most of it seems quite enterprise level, I'm really looking for a simple and easy to use starting point.
What's the current best practice for this kind of setup and what might be a good guide to read or platform to use?
was wondering if anyone had a solution (hopefully simple) for how to change the repository that a SAPUI5 app pulls from.
i.e. when I'm accessing my app (might be hosted anywhere, but for argument's sake lets say on HCP in EU) and I'm in the EU, it makes sense to use the EU repository:
https://sapui5.hana.ondemand.com/resources/sap-ui-cachebuster/sap-ui-core.js
when in the US however, I'm going to get much better performance if I use the US repository:
https://sapui5.us1.hana.ondemand.com/resources/sap-ui-cachebuster/sap-ui-core.js
But short of having a US app and a EU app, how can I achieve this? I don't want to pop-up a request for the user to allow their browser to know where they are via using HTML Geo capabilities http://dev.w3.org/geo/api/spec-source.html and it seems most solutions to map IP addresses to location charge a fee (which I don't want to have to pay)
The standard way for this sort of thing on the web (afaik) would be just to use one address and have a CDN sort it out for you.
This doesn't seem to have happened for SAPUI5.
Anyone know why not? Or perhaps it has, and I just don't know about it, that would also be a very happily received answer.
Now, as of January 2015 there is such a CDN (with geo routing) implemented for OpenUI5 (or more specifically, for everything below the URL https://openui5.hana.ondemand.com).
It does not only serve the data from the closest SAP data center (Germany, USA, Australia), but uses the popular Akamai CDN technology on top, which provides thousands of servers around the world.
See http://openui5.tumblr.com/post/108835000027/openui5-in-your-neighborhood-a-true-cdn-has-gone for more details.
there is currently no such CDN with automatic routing to the closest server, sorry.
Reasons? Lack of time, money, demand...
There may be even free offerings for Open Source libs, but the total of UI5 is larger than your typical JS lib, so I'm not sure they would want it. And in older IE versions the cross-domain loading wasn't working anyway due to missing CORS support, hence a local deployment was preferred. And custom-tailored minimized runtimes for apps are the best for good performance, this is also not something a CDN can deliver. So currently there is no such thing even though it would be obviously good to have.
UI5 will load awesome fast if is part of a real app. Real app means a installable app from an App Store were the UI5 library is part of the app itself and not loaded from a server. That is the real destiny of UI5 and not putting it on a Gateway/Server (the Fiori Way, although there is the Fiori Client which tries to solve this).
I understand that SAP wants SAPUI5 on the backend because of integration in the SAP software lifecycle management. But it is bought with bad performance and caching issues. A very high price in my opinion! Luckily OpenUI5 is free to be part of real apps.
I understand that apple no longer allows me to send "device data" to third-party services. As a result of this, Flurry and presumably every other analytics company no longer collects OS/hardware version data. However, this data is very valuable to anyone trying to target development toward the people who are actually using the apps.
I can imagine a few different ways to collect this data.
1) Send a custom event indicating the hardware/os version to Flurry. This, of course, is in direct violation of the agreement with Apple. However, I suspect plenty of people are doing this, and just not getting busted. Still, not an ideal solution. Even if Apple didn't notice that we were sending this data, I'd rather not have the possibility of the app getting pulled hanging over my head.
2) Use an analytics package which allows me to collect data on my own server. Localytics is one company which seems to offer this. However, I don't think they offer this with their free plan. Is anyone aware of any free (or cheap) analytics tools which will allow me to send data to my own server?
3) Roll my own solution. This could either be an entire replacement for Flurry, or I could continue to use flurry, but send only the device data to my own server. This is a little clunky. I'd much rather have all my analytics data in one place. And would much rather not have to deal with building my own tool if I don't have to
So, is anyone else collecting device data? Are you using one of the above techniques? Or maybe something different I hadn't thought of?
Hi maybe "Testflight Live" could help you.
As far as I know Testflight is allowed by Apple.
https://testflightapp.com/sdk/live/
I've heard of people using UIWebViews to connect to a webpage with a counter. The counter is incremented each time a page is accessed, and the pages are separated by feature/UIView. This way the developer can tell which features get the most usage.
As far as device data, you most likely are looking at rolling your own tracking mechanism, probably going through a server like Google App Engine that's set up to receive your data.
I made this an answer so I could continue to check back, because I'd like to know some more info as well. I voted up your question and favorited it
Good luck, sir
I've searched the web for this bit to no avail - I Hope some one can point me in the right direction. I'm happy to look things up, but its knowing where to start.
I am creating an iPhone app which takes content updates from a webserver and will also push feedback there. Whilst the content is obviously available via the app, I don't want the source address to be discovered and published my some unhelpful person so that it all becomes freely available.
I'm therefore looking at placing it in a mySQL database and possibly writing some PHP routines to provide access to my http(s) requests. That's all pretty new to me but I can probably do it. However, I'm not sure where to start with the security question. Something simple and straightforward would be great. Also, any guidance on whether to stick with the XML parser I currently have or to switch to JSON would be much appreciated.
The content consists of straightforward data but also html and images.
Doing exactly what you want (prevent users from 'unauthorized' apps to get access to this data') is rather difficult because at the end of the day, any access codes and/or URLs will be stored in your app for someone to dig up and exploit.
If you can, consider authenticating against the USER not the App. So that even if there is a 3rd party app created that can access this data from where ever you store it, you can still disable it on a per-user basis.
Like everything in the field of Information Security, you have to consider the cost-benefit. You need to weigh-up the value of your data vs. the cost of your security both in terms of actual development cost and the cost of protecting it as well as the cost of inconveniencing users to the point that you can't sell your data at all.
Good luck!