A pointer in the right direction - web-services

I have been developing a Mac Desktop app with an iOS device counterpart.
Basically I want to upload event information (music gigs etc.) from the Desktop to an online database and be able to read (only) the information whilst mobile.
I've got both apps working, using Core Data (with a sqlite database - I was going to use XML but the iOS doesn't seem to let me do that), but I'm at a loss when it comes to the Web Services part.
I've been googling and checking docs involving sqlite, XML, JSON, NSXMLParser (do I need restful services?)and umpteen other things and I'm just getting nowhere fast.
Could someone explain to me the principle involved? Do I actually need Core Data? Do I have to convert the sqlite data to XML and back again to read it via an iOS mobile device?
I feel I'm making this out to be way more complicated than it should be - or is it?
Hoping someone can put me straight. Hope I've given enough information.

What i do, and I have done many web service iOS apps. I make a webpage in JSON, call it, and then I use SBJsonParser, which parses the JSON into native objects, like a dictionary or array of dictionaries, then I display the data. It really is very simple.
The at a specific time like ViewDidLoad, I fetch the JSON file. Remember, the json document can be web service or just a text file. Whatever you need. JSON doesn't need extra code, is extremely lightweight, and parses without any interference into native objects. Less work for you.

Related

SQLite, iCloud, and maybe Core Data—which to use for storing files and sharing them with all of the user's devices?

I've been tasked with porting personal face recognition software to iOS and Mac OS X as well as helping keep the basic SDK and much of the software as cross-platform as possible. One of the things one of my associates and I want to do is store data on the user's face in an SQL database (probably SQLite). We would also like to allow users to put their data on iCloud so they don't have to train each of their devices separately to recognize them. What's bugging me is how to do both these tasks, and I'm confronted with enough choices to feel overwhelmed. (I am still new to some of the technologies involved.)
For implementing SQL, I could embed SQLite directly in my program and write code for it, or I could use Core Data and have it talk to SQLite for me. (The database is not meant to be shared, so this is OK. And SQL is not fun.) However Core Data is anything but portable (not to mention not intended for a model encoded as C++ objects), while writing directly for SQL would mean we could reuse more code on other platforms.
Things get messier when factoring in iCloud, which has something like five or six possible ways of integrating it with a program. The only method I have definitively ruled out so far is iCloud key-value storage. (At the very least, there's a good chance a user would get into trouble with the 1 MB limit, and it is clearly not intended for anything as complex as I'm dealing with.) Core Data can integrate with iCloud through UIManagedDocument or NSPersistentStore, but, again, that means less in the way of reusable code. I can use SQLite together with UIDocument or NSDocument, but what I am trying to do seems to be not quite what these objects were intended for. The files I am dealing with are essentially large preference files, not meant for end-users to interact with directly; UIDocument and NSDocument seem to be meant for user-viewable and -editable files. And then there are iCloud Drive and CloudKit, which are still in beta. (On the other hand, these two are due to be released fairly soon. Considering that iOS users tend to upgrade to the latest version of the system software quickly, arguments about using either of these based on how many devices they will be able to run on should quickly become weak and obsolete.)
Can anyone recommend which way is best suited for my purposes? Thanks in advance.
Aaron Solomon Adelman
First off, you don't want to try and share the SQLite file directly. That's extremely likely to corrupt the file, because SQLite wasn't built with that kind of use in mind.
However:
You could use SQLite for local on-device storage only and use a separate API to send data back and forth. Apple's CloudKit would probably be a good choice if you can require iOS 8+. Numerous third party solutions exist (for example, Parse). You'll have to write your own code to translate between SQLite and the network API. Your SQLite schema and your data files would be portable to other platforms, and maybe some of the code if you use SQLite's direct API instead of an Objective-C wrapper (and I highly recommend using either FMDB or PLDatabase if you use SQLite).
Core Data does have built-in support for iCloud, which probably makes it a viable option. Your comment that "...I could use Core Data and have it talk to SQLite for me." suggests you might have somewhat misunderstood Core Data. Core Data is not a SQLite wrapper; it presents a completely different API, and uses its own schema. You can't really take a Core Data persistent store file and use it on other platforms unless you want to spend some time reverse-engineering the schema. Also, using Core Data with iCloud does not require the use of UIManagedDocument, though it does still require a lot of other Core Data-specific classes.
If you want to be able to sync data across multiple devices which are not all Apple devices then you need a third party API. None of Apple's cloud APIs will be useful here. There are many providers that can help out with this. For local data storage, either SQLite or Core Data would work, but you should look at the third party services and see what storage option(s) they support, then try to work with them.
The best approach depends on your needs. If you expect to copy data files from an iOS app to other platforms, SQLite is good. You'll still have a lot of platform-specific code, the savings there are much less. If you don't plan to move data files around like that, Core Data is probably easier to deal with.

Connecting to a server in c++ and collecting information

So I am using QTCreator (5.0/5.1) and I am trying to access a website in a way that allows me to access information.
I have built a gui (as this is faily easy) but I want to know how to go about connecting to a network in c++ for my first time.
so for example:
https://btc-e.com/api/2/btc_usd/ticker
I want to get all the information present to me there and store it, the parse it, I just don't know how to connect, to the site.
someone mentioned using the #include but I'm not sure how exactly to use it as well.
If you could provide an example that would be great!
Thanks!
For this kind of task you probably want to use the more high level Qt classes to retreive the page and parse the data. Qt provides classes for both HTTP retrieval and parsing JSON data.
Network Programming with Qt
JSON Support in Qt
Read over those documents, have an attempt at writing some code, then ask specific questions, giving the example code you've tried using and what results you're getting.

Design pattern for webservice should i use

I have a requirement in my project where I will have to built a webservice. This webservice will do the following things:
Accept XML format data
Return XML format data
The XML input data will have an element will have login information and another element data which needs processing.
Now I am looking for a design pattern where in I can make the webservice code look nice neat and clean. Because the webservice has to do plenty of things like.
First Parse the xml
Authenticate the request by checking username and password
Create objects from the data and then save the data to database
Prepare and xml which will be returned to the client.
So I have around 4 major steps which will definately make the code look ugly if I write whole thing in .asmx.cs file.
If anyone can suggest any design pattern to suit this so that the code is easy to maintain in near future.
As this module is to be integrated in my existing project hence there are some restrictions, like I cant use some 3rd party module or dll.
So I was looking for something like Single Responsibilty principle, Chain of Responsibility or Command or Decorator Patterns or anyother oop concept that fits.
I have searched but havent understood which way to start.
Thanks.
M.
I wouldn't write any of that from scratch. Use ServiceStack or MS MVC 4 for the webservice host. Rely upon them to do the conversion from XML to/from your objects. Both of those frameworks include authentication features. Start by reading their tutorials. It sounds to me like you have no experience with ORMs or micro ORMs or the various database options. I'd read a lot of tutorials on those as well.

Techniques to master about implementing a network player

I have a final project abount database design this semester. And my teacher gives us many tasks for alternatives, such as Student Information Management System, Airline Reservation System and so on. However, I want to design such a player that it allows users to upload their own works and share together. Of course it also provides download service. I'm a sophomore this year. I'm familiar with c++ programming, but do not know much about network programming. Furthermore, I learnt T-SQL this semester and also did some works on MySQL in java(course in this semester, too). My idea is here (I have drew a picture):http://tmjfzy.blog.163.com/blog/static/66447025201242553045/
I need some advice about network programming. Could you give me some to help me realize my imagination? Thank you :-).
So, you're basically reinventing YouTube but with dedicated client?
Actually it's very easy to start without any clients or C++ : all you need is a server with MySQL, Apache and PHP. I recommend WAMP server if you're on Windows. FlowPlayer is a flash video player quite easy to integrate, but today using HTML5 video features should be a better idea. I believe you can have the reference Web system up and running in about 3 to 6 days.
(I'm also a C++ programmer and I had no problem with learning enough HTML, PHP and JavaScript to do very similar thing ).
Once you have a system up and running (possibly with limitation on video file format) you can design and implement API. From server side it's nothing more than PHP files, just returning data in your format of choice (eg. JSon, XML) instead of generating HTML.
With server-side API done, you can start working on client. Registration, login, upload from file and download to file should go first. Once the client can get the video files, you can implement a player. A streaming player goes next. If you encounter problems with playing back the video files, this is good moment to break compatibility with web version and change video file format. Now that you know what playback formats are supported, you might implement converting before upload. (Conversion makes sense if you want to have all files on server in one format. Otherwise it's not really usefull: if a client can convert a video, it should be able to play it back. This means all other clients also should understand the format and be able to play it back.)
At this point you can consider rewriting the server. Or other student can be writing the server in the same time as you're busy with client.
Having working Apache-PHP reference all the time makes such parallelism a breeze.
All the above requires using HTTP as underlying protocol. I think Qt has built in support. If not you can use some library (like cURL) or implement it from scratch on sockets.
Eventually streaming, like RTP+RTSP, can be added for playback.
If you feel really adventurous, you can start designing your own protocol, but this is the very last step, after having both own client and own server working flawlessly on hand-implemented HTTP.

flash - django communication -- amf, xml, or json?

We are considering to develop a Flash front-end to a web application written using Django. The Flash front-end will send a simple "id" to the server and in response receive a couple of objects. The application will be open only to authenticated users.
To the extend of my current knowledge (which is basic for Flash) we can either use AMF or take an XML or JSON approach. AMF seems to have an upperhand as there are examples out on the internet showing it can cooperate easily with Django's authentication mechanism (most examples feature pyAMF). On the other hand, implementing a XML/JSON based solution may be easier and hassle free.
Guidance will be much appreciated.
We've used pyAMF + Django on many projects here, and it's a breeze to setup and get running. If you need speed, AMF3 is probably your best bet. It's the smallest/fastest way to transfer data, and serialization is taken care of for you.
On the flip side, setting up json with Django isn't much work either, and it would give you the ability to hook other, non-AMF systems into it without any extra work. You just sacrifice a little speed for that benefit.
If you think you'll ever need other systems working with the backend, or if you think you might switch to an HTML-only, or offer some kind of non-Flash version of your app, I'd go JSON, otherwise, I'd use AMF.
first of all, you should design your app in such a way this doesn't matter. the transport layer should be completely encapsulated, leaving the encoding format transparent to the rest of the app.
personally I prefer JSON to AMF because it's human readable (which makes debugging easier) and there are implementations for every platform/language (so you can reuse the server part with JavaScript for example). And I prefer JSON to XML because it's more compact and semantically less unambiguous as well as closer to common object models. Also it can transport numerical and boolean data in a typesafe manner.
JSON will probaby have the least complications and there's a great google code project that has JSON encoders and decoders here: http://code.google.com/p/as3corelib/