How does one build a directory of 'Spots' for users to check-in to in a native iPhone app? Or, does the developer borrow data from, let's say, Google Maps?
When you Use data obtained from another network or source, you take a risk that the data may change and or may not be accurate, The data may cease to exist, (more so with google, LOL, one minute they are there like gangbusters, the next they are like "Gone" no explanation no apologies, just missing in action, if your developing an application for a business its always best to use your own data sources.
That may be more expensive but its the only way you will have any kind of control over your application resources,.
You can go both ways, it depends on what you want to do and how you designed it to do it. You can have a prerecorded and static database of spots, or you can update it sometimes connecting to some server or you can do it all dynamically by loading each time data from the internet.
Which one to choose? first you shall design your app having in mind something like:
How many times will these datas change
How frequently will these changes happen
How much will it cost to do an update
and so on
Developing your own database of places is likely to be quite an undertaking (and your competitors have a big head start). Google is beginning to provide their Places API for "check-in" style applications, so you may be able to get in on their beta.
Related
I see that many iOS games nowadays don't hardcode their store, and items, description, price etc. are loaded from an external server.
What would be the easiest way to implement this? I am a game programmer with very little experience in server side programming. (Have done hobby PHP scripts a long time ago)
Please let me know what libraries can ease the effort on server side / client side. I would like something that is easy to manage. How do they announce offers like 50% off on certain items etc. whenever they want? Doesn't every in-app purchase manipulation need to get approval from Apple?
Also I would want to maximize security, and prevent the game store getting hacked as much as possible.
You are correct that this has to go through Apple's IAP. You'll want to read about this at https://developer.apple.com/appstore/in-app-purchase/index.html. You setup the IAP items in iTunesConnect (iTC). Your in-app store lists only items that you've setup in iTC, though you can choose not to list every item in ITC. To make your store dynamic, the easiest way is probably to use a UIWebView and then have your store be a series of webpages. This lets you update it on your server easily.
You might check out http://stackmob.com which makes it relatively easy to do just the store part of your in-game store without having all the server admin aspect of it (and associated security). Also, http://urbanairship.com provides hosting for IAP items.
I'm trying to plan out an application on the iPhone/Android that could be used to track dates/locations of events and update them as necessarily but I really have no idea what kind of method I should take.
Currently, there's two ideas for methods in my head:
1) Make a mobile webpage/website that could be updated with the necessarily information, then display this particular webpage/website on the App for users to view.
2) Make an app in iOS/Android to do the above without displaying the webpage at all.
The first idea is the easiest for me to grasp, since I roughly know the procedures of setting this method up. Displaying the webpages on a iPhone/Android screen should be relatively easy and this also allows me to only update the webpage with the latest information and all without (hopefully) building some kind of update system for the app itself.
The second idea is probably the better of the two, since I can make use of all the nifty features in the iOS/Android to make some pretty cool (what are the cool things, i don't know yet) things. I'm not exactly experienced in the field of creating apps, and I really have no idea how to start some kind of self-update functionality on an app, seeing all the apps I've done thus far are offline-based apps that does not communicate with anything save for local files. Should I get the App upon startup to download a file (XML or whichever?) to "read" the contents then update as necessarily?
Or should I just go for the first method, since it can be more efficient than the second one?
I'm really lost here, can anyone offer some tips and advice?
I believe that the first approach is a good one but I would suggest the following:
1- Create the website that will do all the business in your mind then
2- Port out the application in an easy way to be a mobile application how? Please have a look into this http://www.appcelerator.com/
3- Another idea that would save you the pain of going into all the above is to create a facebook application, this way you can make use of the facebook infrastructure and you will have the viral effect as I guess thats what you are looking for.
I hope I've introduced a good tips for you.
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!
I would like to get feedback from all you seasoned developers as to what methodology would be the more "correct" or "efficient" way of implementing my solution.
I have a 4.5 MB flat file that is some 16,000 rows with 13 columns. I know I can import this into SQLite and create my data model but would it be more iPhone efficient to use this file locally on the iPhone or have the application read the data from a web service?
Thanks.
If you are not going to update the data (or only update it when you are updating the app) the local sqlitedb is going to simpler and more responsive. You would probably be even better off importing the data into CoreData, that way you won't need to directly manipulate sqlite or deal with things like synchronous read APIs.
If you want to be able to have the app download updated data the choice because a lot more difficult, depending on the quantity of data, the frequency of updates, how large the changes tend to be, etc.
a local database should always be more efficient in terms of user experience than a web service
I'd use both.
A remote source allowing for a dynamic datastore, and a local datastore with local cacheing seems like a pretty safe bet.
As for the web service. Unless there is any server-side only business logic, maybe give a cloud solution a try. Something like Amazon's SimpleDB comes to mind.
It of course really depends on how static your data is. As everyone has mentioned already if you don't need many updates the most effective solution is a sole local datastore.
Cheers
I guess it depends a bit on how much of the data you need at any one time. If your users need to download a lot of data just to use your application, that would make your app potentially very slow and also unusable without a network connection.
How often do you need to update the data? Frequent updates would favour a web service solution. Otherwise you'd need to update your app and resubmit every time a bit of your data changes.
Another thing to think about: how much do you pay for web traffic for your website? It could become quite expensive if a lot of users constantly need to download data. Unless you use some kind of subscription you only get money once, when you sell the app.
Personally, I'd probably lean towards putting the data on the phone and not using a web service.