I've tried to google this for a couple of days and I am still pretty confused, so I thought I would try here.
I have an iPhone app that uses Core Data with an sqlite database. I am trying to implement a simple backup/restore of the database with Dropbox.
I downloaded the Dropbox SDK, and I have everything running fine as far as linking, uploading and downloading my .sqlite file.
However, I don't want users to have access to the actual .sqlite file for security purposes. I have been seeing JSON on these boards for some time now so I decided to look into it. I think it is exactly what I need.
Easier said than done. I have never worked with Java and have never implemented anything like JSON before, so I have had to try to figure out where to start.
I understand basically what is going on, but I'm having a heck of a time figuring out how to do it. I think I found a way to get the Core Data model into JSON format (and I do use the term 'think' loosely here). But then what - what exactly do I upload to dropbox? Do I somehow combine the model (in JSON format) and the database? What gets uploaded to Dropbox? I'm sorry if this seems obvious to most, it really is not obvious to me, and I have looked.
I am willing to do the work, but it just seems like I could go in 90 directions without some basic guidance and a start. I am not trying to do anything fancy as far as determining data that has been changed, etc. - just want to backup/restore the whole database. I just need some basic explanation and to be pointed in the right direction. A simple core-data sample project would be tremendous.
I'm not an experienced programmer, but I am a fast learner. Just break it down easy...
Thanks in advance.
JPK
Thanks Andrew. I didn't want to 'give away' the database structure of my app, but i can now see that the json string wouldn't be much better than the sqlite file in that area. I am a teach-myself programmer (stay at home mom) so this is all pretty new to me. Maybe I want encryption? But is that allowed for iPhone apps anyway? I recall them asking about encryption when I have uploaded binaries.... I know that iCloud is coming out soon, and I do plan to implement that as well, but with the limited amount of data that can be synced for free, I want to be able to do a simple backup as well. Many of my users have asked for it - a backup in addition to that of iTunes, which really is not a great backup since you can't restore data for just one app (you would have to restore for all apps on the iDevice). Hmmm... Any suggestions as to how to upload the file in such a way that it is not easily readable? Is encryption the way to go in this situation?
JPK,
I think you're crossing multiple streams here.
JSON is a data transfer format. IOW, it has almost nothing to do with the architecture of what you are attempting. You will almost certainly use JSON to communicate with Dropbox.
I have a question: why do you think that the user won't have access to any data you send to Dropbox? I suspect that you are probably wrong. The user will have access to everything.
You are doing to an awful lot of work. You already have the .sqlite file being persisted on Dropbox. If you are doing this to make a backup, that data is being backed up in many other venues. In other words, your task is likely moot and unworthy of your time.
I use JSON, REST networks and Core Data daily. If you have a specific question, I am happy to answer it.
Andrew
Instead of saving the whole database, save out a plist file to Dropbox that you can rebuild a database from. That's assuming you have a lot of extra stuff in your database you do not want the user to see, otherwise just back up the DB as-is if it's all user generated data.
You could also encrypt it but why? Adding encryption only means you have to answer "yes" that you use encryption and may not be able to sell to specific companies, should you choose to encrypt - it's not forbidden.
Related
I'm creating an app which generates a random question from a list (currently stored as a Numbers doc). Once that question is answered by the user, the unique question ID, the question itself and their answer is stored in core data.
When the user requests a new question one will be generated randomly from the original document and it will then be cross referenced with core data to find out if the user has previous answered that question.
I haven't included the code of my app at the moment as I'm not really looking for specific coding help. As someone who is new to the world of code I'm just looking for a nudge in the right direction for me to go and do more studying.
JSON looks like a possible, but the more I read about that the more it seems that it is about an app communicating with a website. I don't really want the questions to be accessed by just anyone, so putting them on my website might not work? Could I do it with a file local in the app? maybe a CSV?
I'm anticipating the file may become quite big as I add more questions - so I'm not sure if that changes things?
Thanks so much in advance, and apologies if this isn't quite the right way to ask questions on here.
I'm just looking for a nudge in the right direction for me to go and
do more studying.
There are many options to solve your problem. Each option depends on your skill, time and if the solution is even necessary for the app you want to make. In the end it's you who decides on which solution solves your problem. There are a few options:
creating your own backend
have a local file in your app
or use a third party service like Firebase.
Each option has its own benefits. Just to list a few:
Local file:
You could have a local file in nearly any format (XML, JSON, .plist) etc. The downside is that your app isn't dynamic - you have to manually keep adding text to this file and update your app trough the App Store for your users to see these changes. If you're going with this approach, I'd recommend using a .plist or a JSON file which is saved in your project. How to implement this correctly is beyond the scope of the question, but there are plenty tutorials out there to help you getting started.
You could put your data in a .plist file. This is nothing more than a dictionary with key-value data (same principle as JSON where each key has a value). An example:
question1 is the key, of type String, containing the value "How are you today". It's easy to read from this .plist since it's the same principle as JSON.
Also, JSON is just a format, it's used often to communicate with websites, but it's not limited to sites only.
Custom backend
This means that you make a backend on which your app can communicate with. You'd have to host your backend, write logic / code on your backend and so on. This can be very time consuming, especially if your app isn't that big/demanding. I wouldn't recommend this unless you have the experience, time, patience and need for this solution.
Third party
This can be a nice solution. Using a third party service like Firebase means that you have your data online. The Firebase library has been well tested and has great documentation to get you started. It's secure, fast, simple but .. it does take a little bit of time to learn how it works - but the end result is that you have a dynamic app where you can add, delete, edit questions and so on. This data can be protected if you wish - which means only authenticated users can access this data (Nobody else will be spying on your data :))
I don't really want the questions to be accessed by just anyone, so
putting them on my website might not work?
Read custom backend and Third Party.
Could I do it with a file local in the app?
Yes. Read Local file.
maybe a CSV?
That's possible but I wouldn't recommend it, but that's a personal opinion. I find it outdated and it's more difficult to work with than JSON.
I'm anticipating the file may become quite big as I add more questions
- so I'm not sure if that changes things?
What is a big file? Nowadays reading a "big" JSON file is probably nothing more than a few MB at most. Your phone reads this in no time. This won't be an issue for your phone or app.
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
Is there a way to decompile the binary from an IPhone app.
I jailbroke my IPhone and was surprised to find other app's dbs wide open to be copied.
So I exported my most important table and hardcoded it into code.
Instead of loading table into array from a db I just generated code to fill the array and kept only the most basic DB info so relationships still work.
Took a while but now works fine.
I was just wondering am I safe, could someone decompile the binary for the app easily and extract the data. In Java its easy to decompile *.class files though thats bytecode where I presume iphone apps are more low level.
I know IPhone sdk 4 can mark files as secure. Anyone know can this be overridden by jailbreaks or is this an unix lock?
Short of encrypting that data, you are really only protected by peoples lack of motivation. If someone with enough motivation wants to look at the data, they can. Even if you encrypt the data, if they key is in, or generated by, your code they can find that too.
To be honest Apple couldn't secure a brick. The iPhone has been almost continuously jail-breakable seance the beginning. Users (read hackers:) have more control over the device than developers. There is no way that you can truly secure content on the device. If encryption is used, there is nothing keeping the attacker from obtaining the key. (He has control over all libraries and can hook any function call he wants.)
It is common to see developers fall back on Security Though Obscurity, and I'm not going to entertain these ideas. If there is data on the device, a hacker can and will make a copy of it.
I jailbroke my IPhone and was
surprised to find other app's dbs wide
open to be copied.
No. There is nothing wrong with this. It has to be stored somewhere.
So I exported my most important table
and hardcoded it into code.
Bad move.
A jailbreak from a priviledge domain is a vulnerability in the phone and is not your problem. There is nothing you can do about that, and even encrypting your data will not save you because all privileged code on the phone will be able to access the encryption keys.
In other words:
Code will not normally be hostile and steal your goods. The only reason it would is because the user downloaded bad code onto the phone or a remote exploit took place.
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.