I am trying to do my first App which is a basic joke app that uses tableViews and allows users to add their own jokes to the app database. My problem is in the networking department and I think I'm getting confused with all that is out there. I have a couple basic questions that I was hoping to get answers or opinions on:
I am really confused about the path that is taken from the app on the iphone to the database that is holding the data. Does the tableview controller call a AFNetworking object, that then sends a JSON object to a server-side script(??), that then queries a SQL database and returns the data? I am just looking for a basic path that allows the user to add their own joke to the database.
Is this a URL request? When I see URL request I think of a web page.
I have a website that is hosted on GoDaddy.com. Is this also sufficient to hold the database for the jokes on the iOS app?
I have been searching for days and have gotten no simple answer. I just want to study the correct subjects instead of wasting time. ANY help or pointers would be appreciated.
You have two forms of storage here - some form of web store (such as a server database technology like MySQL) and the local iOS CoreData (if you want to store locally, or make a new request every time thus requiring a connection). You can use web requests (perhaps using the AFNetworking library) to ensure that the local store and the online store match. A typical flow could be for example - on app launch perform a GET request to pull all jokes from the server using a service URL that returns a JSON file, then update Coredata. To upload a new joke, use a POST request which performs a similar function.
A 'URL request' maps to a web technology which uses some form of logic to determine how to return some data. For example, the request may arrive at a web server (such as Apache) which routes your request to a PHP controller file which then talks with the database and returns your data.
GoDaddy is a hosting platform that supports PHP and MySQL (amongst other technologies that will do the same trick), so yes.
In your situation, I would study the Model-View-Controller design pattern. Your app will be a great learning experience I think, you should pick up a lot of core concepts.
EDIT to answer your question in the first comment:
Your question:
1. Are JSON files stored on the device or the server? 2. Does JSON replace JavaScript?
Answers:
JSON is short for JavaScript Object Notation, it's just a way of representing data and doesn't replace anything. It's particularly useful because most languages support parsing JSON in a way that the technology understands. It's a handy way of sending data around because it's pretty lightweight and is widely supported.
In a case like this, the JSON would probably not be stored on the server. The data would be stored in a database. Your request will be mapped to a server side technology such as PHP or Ruby which will then ask the database for the information, convert it to JSON for sending and return it to the client. (It is possible to store data on a server in a JSON file, but you would have to write your server side code to manipulate the JSON file directly, it would be hard work and way less elegant!)
The client (in this case an iOS device) will parse the JSON into an object that Objective-C can play with, like an NSDictionary.
Hope that helps!
Related
I am about to build a CRM application in CakePHP. The CRM will require an API for other applications to extract the data.
Applications that are not on the same server will obviously access this via some sort of API caller object that makes an HTTP request to the CRM.
As I understand it, the HTTP request time will increase to the overall load time. For applications on the same server is it possible/is it common practice to access the API by some other means. i.e. including the controller and using the actions ... (im not even sure if this would work as the framework wouldn't be bootstrapped right?). By doing this I am looking to: 1) Reduce load times. 2) Return data as PHP arrays instead of json/xml objects.
In order to return HTTP responses then you need some kind of HTTP server, API's are designed for exactly the reason that you are describing above - they allow multiple applications to access the data in a database by creating an interface to it in a way that can be controlled and standardised.
If you design your API well, have it return JSON objects then the average response shouldn't be a problem as you will only be returning a small amount of text.
Getting a PHP array from a JSON object is as simple as json_decode($json_object, true);
If you are using CakePHP to create an API you should look at using the awesome CRUD plugin by Friends of Cake
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.
Recline.js seems a great tool to display data on grids, maps, etc.
I'd like to use the grid views, but to be able to save what is displayed to the user on a database. I'm currently using rails for this project.
In the docs, they say how to code a backend to integrate with it (http://okfnlabs.org/recline/docs/backends.html) but i wonder if there's already someone working on it ( I couldn't find it on the web)
Thanks
The Backend object in Recline.js a javascript component that talks to a data source of some kind, typically a web service. The Backend component talks to the interface of that web service, and it doesn't care whether it be programmed in Ruby, COBOL or Java, as long as it knows where to get and send the data, and in what format.
So in short there isn't, and can't really be a ready Rails backend, because the implementation depends more on the specifics of your application -- how to map the data in your database (MySQL?) to a service API Recline can understand, and vice versa.
You can use SOLR with Rails, so I dont know why you couldn't utilize the Recline.js SOLR functionality to search your rails data.
I have an app that relies on some key value pairs where the value could change at a point in the future due to 3rd party api. The app is only useful when connected to the internet by the way. If any values change I don't want issue a new version of the app - I would rather that these values were pulled from a webservice/static xml file on my server. I would only need to pull these if I encountered an error.
Is there a standard way to do this or should I just roll my own?
EDIT: I'm not so interested in a server side technology - I think a flat file will suffice. What I'm interested in is what format should the flat file should be and how to cache it into my application once I get an error.
try redis, high-performance key-value store. used by some of the big cloud players, like cloudfoundry. Have a look at http://redis.io/. Objective-c client is available at http://redis.io/clients.
I figured out the best way for my use scenario:
I setup a json file on S3 which required authentication. I then used AWS for Objective C to authenticate so I could access that file.
I decided that I only needed to update the local info when the applicationDidBecomeActive in the App Delegate. I then got the json async and on success I then checked a version number in the json and if outdated wrote the changes to NSUSerDefaults (which are then used through the app.) If there was an error getting the json file I just continued as I would already have the previous set of NSUserDefaults that would do the job until the user next made the app active.
This solution worked best for me as it's simple to maintain and should easily handle the load even if my app were popular.
Have you considered using iCloud? It has support for key value pairs. More info here: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/iCloud/iCloud.html
I have written a simple database driven app in C# which uses a 2 table MySQL database. This is all a learning curve for me (except c#, which I am now comfortable with)
The app is small, has a couple of datagridviews, uses a few sql select/inserts statments to populate the datagridviews and also update records.
I want to port this app to Android. All of the internet sources I can find recommend a middle php sript which accepts http requests in order to fetch the data from MySQL and then return the results back to the android device where it is parsed with JSON etc etc.
This method is a little out of my reach since I dont have php experience, all of my attempts to implement the php layer have failed, speciially the android app was not receiving any data back, I'm assuming I messed up somewhere inside the php file.
Is there an easier (more noobproof) way to interact with the MySQL database from within android which doesnt require the need for php + JSON? Any ideas are appreciated, thank you in advance.
If you are comfortable with C#, why not use ASP.Net MVC for the middle man?
MVC is especially easy to deal with JSON, and you actually only need to create those "controllers" (as models should already be there from your existing app, and JSON don't need the View to display).
You can create a Web Service with C# that handles the data retrieval from the database; no need to go with PHP. Try create one with WCF API (check this question in order to create one). In order to create an Android client that consumes JSON on Android check this link.
If your mobile application have to access a database over the network you should indeed build a web service fronted to the database.
By putting a web access layer on top of the database you can expose the required queries in an abstracted, secure and convenient manner.
Though this sort of web service architecture can be implemented with PHP + JSON other technologies can be used as well. If you feel more comfortable with C# you can use it to build the web service instead. By doing so you may even be able to reuse some of the code from your existing application.
Actually, it would be better to take php in middle of android & mysql, due to the security concern and by the way this is the most easiest & comfortable method. here is link link. I hope you like it.