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.
Related
I have been researching this all day, its more of a question to see if anybody can help.
I have already set up the push notifications on my iPhone app which i had a nightmare with but I've managed to do so.
I'm only a internship and have been developing apps for 4 months, its not my strongest subject as I haven't learned anything like this at uni.
My boss has asked me to add a view to the application so that you can view the most recent push notification that the app has received.
I know this is possible but I'm not sure how it's done, I have spoken to the developer who dealt with all of the server side of things (he doesn't have any knowledge of app development).
He said I would need a page that will read directly from the SQL Server database which he has written the code for that stores all of the pushed notifications.
I have mentioned that it wouldn't be a good idea as it can be prone to hacking etc. He disagrees.
Can any one help with what I need to do? Or does any one know of any tutorials I can follow to help me with this.
One route to take is to make a copy of that Database and put it on the phone as an SQLite Database and have a PHP script that gets the newest additions and adds them to the SQLite database.
A second route you could take, is you could ask him to put it JSON format and you would have a dictionary on the phone that held all of the JSON, and then parse the JSON using apples built in parser, NSJSONSerialization or any of the other JSON parsers out there. Using the parsed JSON, you could then do as you please with the list of notifications
Another method will be for that guy to write a PHP script for you to access all the notifications and you run that in a for loop and populate a table, or whatever, on the phone of the latest push notifications that way. This while take a few seconds longer than needed, depending on how many entries there are.
Ordered according to my preference of options
Since you fairly new to mobile app development I would recommend option 2 for you. It will be a bit more work than choosing option 3, learning curve wise, but it will run faster and be better for you to learn how to parse JSON, as a lot of API's that you come across use that format.
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.
I'm new to iOS Development and am trying to make an application that essentially sorts through a list of 300 names or so. I've got the Drill-Down part of the application down, aside from the detailView, but am now faced with a challenge.
What I would like to do is have users select from 3 fields with a UIPickerView to come up with shorter lists for every time a user is looking for a person. I'd like to use a .plist, but I also have an XML feed of the information. Before I waste all of my time structuring these data sources, does anybody have a good overview as to how I should approach this?
Also, I've asked some this question before, and they tell me to read up on introductory iOS development topics. I understand the mechanics of development, I just can't ever figure out how to approach a task properly. (I'm working on it!)
Thanks in advance. I'd share an image to help clarify, but my rep isn't high enough.
Snip: It looks like I misread your intention which makes my earlier comments irrelevant, you want to have the user select one of 3 options to shrink the list, if I'm not mistaken.
Some more questions for you, so I take it that this XML feed is going to be potentially changing between times that the user loads up the app? Will it only ever grow or are those 300 or so names that are loaded once set for good? The reason I ask so that you can maybe see my train of thought is whether or not using Core Data might be useful. You could easily store your large list locally, save time having to reload this large list frequently, and also you can use the built fetchedObjectController to search your collection of names. I'll keep thinking about it and once you get a chance to answer these questions we can continue.
Ill check back for an edit or comment, and see if I can give you an approach. Also, maybe edit your question with any of your own approach ideas and we could also start from there and refine them if needed.
Edit 2: From the information in the comments this is one of the ways that I could see this being done that make sense to me:
Since you seem to be able to control the information you receive from the feed I would set it up to send you only the contacts that need to be added/removed. You could handle this a few ways depending on your deployment intentions but I would go with the following:
Find a way to signal a first time run of the application, and as a result all contacts would be new, and you could populate your list fully with a slightly longer first time setup. Then any further changes could be quickly handled by smaller edits made to the local list.
You would need to set up Core Data for your application, which should be fairly straightforward in your case, and after this you can use the built in NSFetchRequest to do your searches that will then quickly return a list of narrowed down contacts. As for the physical picker that is just a matter of building the UI which will require some design from your end as you are the only one that knows what you are going for in that regard. Depending on the complexity of your app and what functionality you will want to include you could get away with 1-2 views that simply do the displaying of the contacts in a table and then the picker just reloads when appropriate.
I'm not familiar with the implementation of XML Feeds and receiving data from them, but I have done XML Response parsing into Core Data from a SOAP service before and they shouldn't be terribly different.
Regarding resource to get you started should you need them, I would recommend the following:
eBooks:
http://www.techotopia.com/index.php/Objective-C_2.0_Essentials
http://www.techotopia.com/index.php/IPhone_iOS_4_Development_Essentials_Xcode_4_Edition
Tutorials:
http://www.raywenderlich.com/
The eBooks I have linked are both absolutely fantastic and one of the few xCode 4.0 books that I was able to find that seemed to be of an actual usable quality. They both contain easy to follow and clear tutorials on simple and more advanced aspects of programming for iOS.
Ray's site is an immensely helpful resource as it contains both a very active forum base for iOS programming in addition to a constantly growing tutorial collection as there are 4-5 people that constantly are creating new tutorials that the community votes on and suggests every week. It contains some more advanced topics than the above books and I would recommend looking at it after doing a few walk through/tutorials from the books.
I'll stick around if you have any further questions, otherwise you can send me a notification via these comments, or just post another question and someone is bound to help you out!
-Karoly
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'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!