Ok guys, so im new to iPhone development, so apologies if this is a silly question, but before i actually create my app i want to know if this is possible, and if Apple will reject this.
(Note this is all theoretical)
So i'd have a API (.NET) that runs on a cloud server somewhere and can return HTML/JSON/XML.
I'll have a website that can access this API and allow customers to do some stuff (but this is not important for this question).
I would then like my iPhone app to make a call to this API which would return JSON data. So my iPhone app might make a call to http://myapp/Foos which would return a JSON string of Foo objects. The iPhone app would then parse this JSON and do some funky stuff with it.
So, that's the background, now the questions:
Is this possible? (that is, call an external cloud API over HTTP, parse JSON response?)
What are the chances of Apple rejecting this application (because it would be calling a non-Apple API)
Are there any limitations (security, libraries, etc) on the iPhone/Objective-C/Cocoa that might hinder this solution? In regards to Security - can you freely make a HTTP (or even HTTPS call) from inside an iPhone app, and parse the response? In regards to libraries - is there sufficient support in Objective-C/Cocoa to accomplish this?
On this website, they seem to be doing exactly what im asking.
Thoughts, suggestions, links would be greatly appreciated...
Yes. It is possible. There are quite a few apps that do similar things.
Slim to none. Apple hinders what languages and libraries you can develop in and run on the phone. They won't limit you based on what external data you pull in to your app.
There shouldn't be any worries here either. You shouldn't run in to security concerns and there are plenty of libraries that you should be able to utilize to make your life much easier.
Good luck!
Yes it's certainly possible, and there are json parsers available already. Secondly, based on what you just described, should the application not break any rules outside of the scope of this question, then there is no reason I can see Apple rejecting it (except perhaps content, ie., don't display any porn or the like :)) ... Finally, you haven't properly described your application to fully answer #3, and I don't dare guess at what you meant, since it may be just a waste of your time. Feel free to expand on your #3 in comments, I'll answer there.
Edit: With regard to your edit of #3 above, yeah you won't have an issue here at all either.
Related
I need to develop a client application for a site that host and show images.
The client should shows all new images and take a picture and send to website.
I'm a newbie to iOS programming so this question:
In an application alike this, there's the need to create a Model? I ask this question because I think I can do anything with Controllers but maybe I'm wrong.
While there is never a "need" to create a model, it's good form to do so, and it'll likely save you many headaches down the road. Ultimately, you're going to need to deal with images and websites and how they interact with each other and whatnot, so you might as well do it in models from the outset.
I'm as guilty as anyone for wanting to see immediate results and hack together something quickly, but I always regret it later on, and have to spend more time than I'd expected refactoring it into something usable.
The MVC pattern as used in Mac OS and iOS applications isn't something best explained in an answer box but here's a link to some simple documentation about the roles of Models, Views and Controllers
Some good basic introductions to start with, which also have relevant links to the next stage of documentation are:
Cocoa Core Competencies
Cocoa Application Competencies for iOS
Read these excellent articles first. You'll learn better and faster if you do some basic reading.
How do I implement activesync protocol in iphone app?
Any advice, any docs and tutorials are well come.
I have read the Exchange ActiveSync and iOS 4 Devices from apple.
Is there any real docs for this?
Despite having asked a question in the comment, you might be looking for the Microsoft documentation of the Exchange Server Protocols.
If you're thinking of implementing your own client though, I would strongly advise you to pause and consider whether it's really worth it. As someone who's worked on a server-side implementation of these protocols, I can tell you they can get pretty complicated - and the documentation doesn't always give you enough information. (In some areas it's flat out wrong, too.)
It is hard, but not impossible to write an app which communicates via exchange active sync. The link to the Exchange Server Protocols in Jons answer contains a document named MS-ASWBXML. You have to write an encoder for wbxml on your own and the document describes clearly the needs. Additionaly I recommend strongly this document: http://www.w3.org/TR/wbxml/
If the low level is working, you have to implement the EAS-protocol on top ob wbxml, which is not trivial, because of bugs in the documentation, different behaviour of different protocol versions. It will be a lot of trial an error to examine, why the exchange server does not understand your requests ;-)
Using Apple's built in support just means using Apple's APIs for writing to the Address Book and Calendar Store on the phone. Your app isn't supposed to know anything about the way that data is synchronised: it just happens in the background.
If you want direct control over the synchronisation process, then Apple's APIs cannot help you. Jon Skeet's answer contains a link to Microsoft's protocol documentation, but as he mentioned you'll be setting yourself up for a world of pain.
EAS is really meant for device makers to implement and not normal application development. You should look over the ActiveSync Protocol documentation and look into licensing the protocol (yeah its a pay-for license) and then ask yourself if its worth all the trouble to write all the business logic, ecoding logic, intensive testing and the licensing. An alternative is to use Exchange Web Services (EWS), which might be a much better fit - more rhobust in many areas and no licensing needed.
You should also look at this: http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx
I think that seem is more good performance , but have not use in app.
I have use the kit in a test app, but I found the code seem is not good, some exception does handle , the test app crashed like when connect failed, I have to modify the core code of the kit to solve such problem.
I am not sure whether the lib code is stable ... anyone have experience on this field (choice which solution, XML JSON or other ) ,
thanks.
I am not too sure about this question. But here is my 2 cents.
HessianKit has 40+ new downloads per months.
Not super well known.
It is in use in more than 20 live apps on App Store projects that I know of.
Tested in real production, both games and business apps.
The license is very forgiving.
So I have no clue about real total usage out there.
HessianKit pros:
Works effortlessly with existing Java servers.
Just as easy
Almost non-existing manual glue code.
Server calls treated just as any other method call.
Just avoid calls from main thread as with any IO.
Payload is small, as in freaking tiny.
On celular network this actually matters.
Hessian cons:
Communication payload is not human readable.
I am biased, since I am the developer behind HessianKit. If I was to suggest anything else, then I would say JSON. For the following reasons:
Human readable.
Buzz-word friendly.
Are there any guidelines on pitfalls to avoid while developing iPhone applications?
Sure, thousands. The same is true for any software development. Unfortunately, the easiest way to enumerate them is to write them down on a sheet of paper while waiting for a friendly soul to release you from the one you just fell into.
However:
Don't try to reinvent the wheel. The iPhone API is very complete -- you just have to LOOK for the facility you need. Things are NOT always implemented the way you would expect. Read the guides, carefully. Look at the tutorials and analyze how they work. (Try changing a line here or there in the tutorial to see what difference the change makes.) The single biggest mistake I have made in 1 year of iPhone development is not trying hard enough to find the iPhone way of doing something.
Don't ignore memory management; master it early and often. Use the Object Allocation and Leaks tools in Instruments to check for memory leaks frequently. I'd recommend checking after you complete each feature or view; more often than that if you keep finding bugs. Eventually you may understand it so well you can stop doing this.
Don't just use the default build settings. Play around with them to understand what they do. Figure out certification and distribution. GET INTO THE DEVELOPER PROGRAM QUICKLY -- it can take a while to push through that pipeline. [ AND when you get that notification that you need to renew, get it on instantly -- there have been problems with that process. ]
Don't neglect to read the Human Interface Guidelines (HIG) carefully. If they say not to do something -- DON'T DO IT. Apple will reject applications that misuse their iconography.
Don't stint on marketing. Yes, the App Store puts your app in front of millions of people... In theory. But the odds of getting front-paged are slim. There are a lot of great apps on the App Store that haven't sold much because no one knows about them.
Don't rest on your laurels. If a new technology comes out, find out if it makes your job easier; if it does, take the time to learn it. Personal example: I'm just now trying to switch from SQLite-based data management to Core Data, because I was in a hurry at the time I started my most recent project; now I wish I had slowed down and thought about it.
Don't go into your design thinking (for example) "How do I implement my concept with a table view?" It's true that table views are natural for many informational and utility applications, but don't be constrained. Instead, think about what users will want to be able to do, how you can make it easier for them -- put things together that will be used together, etc. If you've never explored the concept of Use Cases, read up on them.
Don't hesitate to build composite views. Many of the questions I have seen here on Stack Overflow have to do with putting a toolbar at the top of a table, or having an image in the background of a text field. I understand the desire to do things the easy way, and as I state in #1 above, if there is an easy way, use it. But in many cases the solution is just to layer a couple of views with appropriate placement and transparency.
Think about what might be Apple-approved from the start.
App Rejected is one of several useful sites to help understand Apple's mostly undocumented standards. (One more.) (A previous question on app store rejection reasons.)
A few quick examples:
Using a UIWebView can get your app a 17+ rating.
Coding with an undocumented/private API = rejected
Version number < 1.0 might= rejected
Not enough feedback about network success/fail = rejected
Too much network use = rejected
Clearly limited free version vs full version = rejected
The word 'iPhone' in the app name = rejected
The above links contain many more examples, and more details about those examples.
Don't neglect the programming guides. While the documentation is quite extensive, the programming guides contains a veritable trove of useful tips and "insider" information that simply cannot be gleaned from reading method definitions. I spend just as much time reading the guides for a technology (say, Core Data) as I do actually implementing it.
Don't assume you know what a method does. If you have any degree of doubt about the functionality of a method, it is well worth your time to go look it up in the documentation to verify.
Wonderful examples from #Amagrammer above.
I would love to add that the first place to start is iPhone development is Photoshop. This is still the best advice I can give to anyone who is starting out. I now use OmniGraffle because it has awesome stencil templates.
What I find is that even for super simple app's, draw up your prototype and look for usability issues and work flow issues. It is 100x quicker to redraw your app than re-code it. I have fallen into this trap numerous times and now actually draw up some pretty simple functionality to see what it will look and feel like.
This advice will save you 10s maybe even 100s of hours in hopefully getting your app right first time and getting you to think through what the issues are. Throwing away code sucks and I have done it not because the code was bad but because it made the usability or solution worse. I think the best of us end up throwing code away and prototyping your design definitely will help in having to RTFM for something you did not have to build in the first place.
If you don't have an great designer, and can't do great design by yourself, then don't even start iPhone app development. This rule only applies if you want/need to make money with your apps.
If I have make an application, how would I make it interact with a database on a server of mine? I'm kind of lost, and don't know where to start.
Vague question yields a vague answer.
It entirely depends on what kind of interaction you need. Lots of constant queries? Few and far between? Client side cache? Real time updates? All of these questions will impact the answer.
The easiest way is to go with an AJAX style HTTP based client/server type of interaction. Sticking a database behind a web server has been done about a bazillion times and, thus, you'll find lots and lots of examples and, even, solutions with a few google searches.
You don't really need to use JavaScript (the J in AJAX). Instead, send over an HTTP request that encapsulates your query and have the server respond with an XML document containing the answer.
If that won't work for you -- too much overhead, need to relay binary information (for which XML sucks), etc.. -- then you'll wan to go with more direct access to the database. That is harder and can range from porting a client library to the iPhone to creating your own wire protocol.
A significantly harder problem and you'll have to deal with networking issues -- firewalls, NAT, proxies, etc... -- that are generally already solved with HTTP.
Stick with HTTP until you prove that it won't work. Much simpler.
Search for "http request" in the iPhone docs. HTTP client APIs are included.
You might try Apple's "Getting Started with Networking & Internet" or "Introduction to the URL Loading System", in addition to the Networking section of the iPhone Application Programming Guide. There are also several sample applications that handle networking of various types within the ADC's iPhone section.
Additionally, there are a number of open source iPhone applications out there that handle networking, including my own.
I had a similar question regarding a rails app - the answers there may help you.
What is the best approach for building an iphone client for a rails app?
But the answer really depends on your knowledge of iphone programming and server side programming, plus how your database is set up at the moment - but most likely you're going to need to write some kind of webservice / REST API that allows a remote client to do things with your database.
There are many frameworks available for that on the server side - if you're starting from scratch, ruby on rails may be a good choice.
On the iphone side, you'll probably want to start by reading up on NSURLConnection, and various request/response formats that you can use with it. I've found exchanging plists between the phone and server to be a pretty easy approach.