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.
Related
Ive made an enterprise Universal (iphone/ipad) app that uses the odata sdk to talk to an sql server database. All great, works fine. The issue (well not really an issue, but somewhat of limitation) is that it is a connected solution, if you want to retrieve or update information you have to be connected to the internet.
Im now trying to add disconnected functionality. My question is, is there a way of saving large (relatively large) amounts of serialized data to the actual device. I dont want to store it in the application because
it will build memory up in the app really quick
if the app crashes they will lose the data
Any ideas on how I can go about this?
Use Core Data... Apple has very good documentation, check it out!
It sounds like you want to synchronize data between an online system and the device. Synchronization is a very difficult problem to get working perfectly. If your web service is REST compatible I would look into RestKit as a solution for communicating with your online system and storing that data in Core Data locally on the iPad.
Ultimately you want to replicate the data online with a database locally, I would recommend Core Data for this if it is a large amount of data. Core Data alone is a complex framework and will require a good amount of understanding.
There are a lot of things to consider, how much data is needed offline? Can you perform delta syncs? How is data moved around and what steps are necessary for moving the data in the local database when moves occur remotely? How do you detect that a record was deleted online and therefore needs to be deleted locally? Can you users edit existing data while offline? What do you do about merge conflicts (same record is edited online and offline)? You will want to think about all of these scenarios.
There are some systems out there that can handle some of this for you, if your online system is also in development you may consider CoucheBase which has a mobile counterpart that handles this tricky synchronization problem for you.
Good luck!
Core Data is the way to go.
http://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GettingStartedWithCoreData/_index.html#//apple_ref/doc/uid/TP40005316
I have data that I need to organize, and the easiest way to do it would be with CoreData. I also want to sync this data to Dropbox so that it will be synced across multiple iOS devices and Macs. I looked at this post, and now I am kind of concerned:
You want to look at this pessimistic
take on cloud sync: Why Cloud Sync
Will Never Work. It covers a lot of
the issues that you are wrestling
with. Many of them are largely
intractable.
It is very, very, very difficult to
synchronize information period. Adding
in different devices, different
operating systems, different data
structures, etc snowballs the
complexity often fatally. People have
been working on variants of this
problem since the 70s and things
really haven't improve much.
I am especially concerned because I am pretty new to iOS and programming in general, and I was hoping it would be easier. I was wondering if anyone had some tips/tutorials/experience with doing this. I could use property lists (or a different method) to store the data, but that would make it harder later in case I wanted to change any of the attribues for the data I am storing. Is this really as complicated as they are making it sound, and should I just try to find some other way to sync the data (e.g. email, drag and drop in iTunes, etc.)?
I don't have any experience with cloud sync, but I do have experience with data management. Plist files are not at all bad in terms of data manipulation. The main problem with plist files is speed when handling large amounts of data, but for what you are intending to do they should work fine. It is difficult to provide more of an answer because in your question you did not say what kind of data, or how much data, or how often this data will be changed/accessed. If you are a beginner in iPhone development of programming in general, I will just say that Core Data has a very steep learning curve. When i first started programming for the iPhone all I used were plist's because they are simple and versatile.
Also, from reading the article that was linked in your question, it seems that he was condemning cloud providers for the way they handle data storage, and the services offered to the users. That article was written in 2009, since then great strides in "cloud" storage and syncing have been made. Also, you are not actually creating a cloud sync service, you are simply using one that is already in existence, so almost none of those problems apply to you.
Syncing is rather easy. You just have to keep track of file creation and deletion.
I wrote this blog post about how to sync a local data store with a remote one: Basic Syncing Algorithm
In the comments, tell me what (in general) you are using CoreData to manage. I need more information.
Now there is a product to sync your CoreData across devices with the data being stored in your's Dropbox, Box, or Google Drive account. It's called NimbusBase.
You can directly use your CoreData, import our libraries, and your data will be saved straight to your's Dropbox. We handle authentication and also moving the data back and forth.
Feel free to email me at admin#nimbusbase.com if you have questions.
Disclosure: I am a programmer at NimbusBase
I am writing an iPhone app, that requires cloud back-end DB storage. I have a couple options in mind, and was wondering which one is better fit?
What I need:
be able to perform GRUD in the cloud from the iPhone app
the DB needs to scale (speed-wise) without much or any management
schema free
all i need is to store maybe 1 million records
Google App Engine:
Uses bigTable, scales, and schema free, but I need to write a RESTful interface
CouchDB:
Recently released iOS support, RESTful built-in, but I worry about scaling when syncing with remote server
SimpleDB: (seems to be my best pick)
Has iOS SDK, so I can do GRUD directly, auto scale (I probably won't be running into the 10GB limit), schema free
MongoDB:
Don't know much about, from what I hear, it's faster than SimpleDB, and easy to setup, but again I need to do the admin work
Cassandra:
Too much work, for what I need.
Any insight or feedback or correction is great appreciated.
Regards,
Johnny
If you're looking for zero management on your end, then you've already answered yourself that SimpleDB or GAE are probably your best options.
SimpleDB is probably better in your case, because it'll save you from having to write a simple RESTful interface on top of GAE.
Note that both of them aren't great in terms of speed. I worked with both and there's visible query latency. Unfortunately there's no way for you to tune that - you're completely in the hands of Amazon/Google. That's the price you pay for not managing the datastore yourself, so I guess you'll have to decide if you're willing to pay that price.
I recommend that you try SimpleDB, which is simple enough, first. If latency is a problem then you can move to hosting and tuning your own Mongo or some other option.
SQL Azure Services. Meets your requirements above.
http://en.wikipedia.org/wiki/SQL_Azure
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!
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.