Background: I am about to start preparing my 1st framework for my clients, so they can easily integrate it into their apps and fetch data from my servers without dealing how communication with server is working. I chose ASIHTTPRequest library for communication.
Question: how should I deal with ASIHTTPRequest or any other static library - make it a part of my framework or let adopters link against it themselves in their projects?
I'm opting to make it a part of my framework, so I can prevent users from setting breakpoints in ASIHTTPRequest and easily access/log connection frames/data. But what would happen if my clients will need this library for their own purposes? Will they be able to link it second time? Won't it cause any run-time collisions?
Sorry for wording... Please let me stand corrected if I'm confusing any terms :)
Look at how ASIHTTPRequest handle it :)
They make you link against lots of the iOS frameworks but they don't ship them with their download.
However, they do ship code for Reachability with their library - if you don't already have it then you can include it. If you already have it in your project then that's OK too.
I would ship the source of ASI in a seperate folder - then your users can either include it or not.
That also has the benefit of ensuring that the version of ASI they use will work with your library ;)
(see the ASI docs here)
There are two different types of frameworks to consider, so I would do two things:
For any third party library like ASI that you use, include a
directory with the source as deanWombonurne indicated. Make sure to indicate which version of the library you have included if it is not clear (add a VERSION) file if needed or name the directory).
For Apple frameworks, include a manifest file somewhere that gives a
list of all the Apple frameworks they should include in their
project to satisfy your framework requirements.
Related
I couldn't get clear idea in differences between framework and libraries, can you suggest your idea or refer me any website or article thanks.
Apple's Doc is always a good place to start:
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html
In sum, Frameworks are an Apple specific mechanism for packaging dynamic code in a well defined directory structure. Frameworks are a particular type of Bundle which allow for versioning, storing and loading resources (icons, string files). Dynamic libraries provide only the shared module (with the *.dylib extension).
Note, OS X supports both methods, but Frameworks provide a great deal of flexibility both in development, deployment and management and are usually the preferred choice.
Using Frameworks requires compiler/linker specific flags to properly use. You should consult the Clang/XCode documentation.
I've recently read the news on http://allseeing-i.com that ASIHTTP is being discontinued. I have much respect for the makers of the library. However, I am now looking for a substitute that also supports queued download (multithreaded) on iOS, that also supports a progress bar with appropriate information.
Is there any (hopefully lightweight) library, that is in an active development livecycle? ARC support would also be much appreciated.
Many thanks for your thoughts.
You may want to look at MKNetworkKit. In its words:
MKNetworkKit's goal was to make it as feature rich as ASIHTTPRequest yet simple and elegant to use like AFNetworking
It has a number of very nice features for queuing and managing offline situations.
AFNetworking is being lauded as a successor to ASIHTTPRequest. It is based on operation queues, and in my experience it works reasonably well. You could probably do what you want to do without a third-party library, but if you want to make it a little easier on yourself, a combination of AFURLConnectionOperation subclasses and the AFHTTPClient class will do nicely.
I wrote one recently. It's fully ARC compliant and fairly lightweight:
https://github.com/nicklockwood/RequestQueue
As of version 1.2 it supports download and upload progress bars (see the included ProgressLoader example).
Rather than make a monolithic framework like ASI, I've tried to keep this as simple as possible. That means you are free to mix and match it with other libraries for stuff like POST parameter generation, JSON parsing, etc.
I want know about how to create dynamic library frameworks for iphone..
Any ideas about this..please guide me...
Dynamic linking is forbidden if you want to deliver to the App Store (apart of the Apple provided libraries and frameworks, of course). Only static linking of external libraries is allowed by Apple.
Edit: (quoting myself from a comment to a different question) The reason is security: since a dynamic library can be loaded and unloaded at runtime you could download additional executable code and load it (think plug-in). This could get compromised by a hacker and then having malicious code executing on your phone is a very bad thing. It would also make it possible to add unapproved features to an approved app. In short: in this environment, Apple considers dynamic linking to be a Pandoras box that must be strictly controlled, otherwise it could compromise security and I agree that it does make sense on the phone.
This simply isn't supported for various reasons.
Use static libraries instead, or compile the source directly into your project.
(Presumably the following question is not iPhone specific, aside from the fact that we would likely use a Framework or dynamic library otherwise.)
I am building a proprietary iPhone SDK for a client, to integrate with their web back-end. Since we don't want to distribute the source code to customers, we need to distribute the SDK as a static library. This all works fine, and I have verified that I can link new iPhone apps against the library and install them on the device.
My concern is around third party libraries that our SDK depends on. For example we are currently using HTTPRiot and Three20 (the exact libraries may change, but that's not the point). I am worried that this may result in conflicts if customers are also using any of these libraries (and perhaps even different versions) in their app.
What are the best practices around this? Is there some way to exclude the dependent libraries' symbols from our own static library (in which case customers would have to manually link to both our SDK as well as HTTPRiot and Three20)? Or is there some other established mechanism?
I'm trying to strike a balance between ease of use and flexibility / compatibility. Ideally customers would only have to drop our own SDK into their project and make a minimal number of build settings changes, but if it makes things more robust, it might make more sense to have customers link against multiple libraries individually. Or I suppose we could distribute multiple versions of the SDK, with and without third party dependencies, to cover both cases.
I hope my questions make sense... Coming mainly from a Ruby and Java background, I haven't had to deal with compiled libraries (in the traditional sense) for a long time... ;)
If it were me I would specify exactly which versions of those 3rd party libraries my library interoperates with. I would then test against them, document them, and probably deliver with those particular versions included in the release.
Two things I would worry about:
-I would want to be sure it 'just works' when my customers install it.
-I wouldn't want to guarantee support for arbitrary future versions of those 3rd party libraries.
It is fine to include a process for the customer to move to newer versions, but if anything doesn't work then I would expect the customer to pay for that development work as an enhancement, rather than it being a free bug fix (unless you include that in the original license/support arrangement).
At that point it becomes an issue of ensuring your specific versions of the 3rd party libraries can work happily alongside anything else the customer needs (in your case a web back-end). In my experience that is usually a function of the library, e.g. some aren't designed so multiple versions can run side-by-side.
Has anybody done or seen a deployment of Apache Thrift in an iPhone app?
I am wondering if is a reasonable solution for a high-volume, low(er)-latency network service for iPhones compared to HTTP.
One noteworthy thing I found is a bug report about running Thrift on the iPhone, which seems to have been fixed. But that doesn't necessarily indicate that it's a done deal.
Thrift and HTTP aren't mutually exclusive. In fact thrift now ships with an HTTP transport implementation to use. It's also a really nice way to auto-generate server/client code that avoids a lot of marshalling/unmarshalling boilerplate while still being really fast. Its internal representation is basically binary JSON, so it's very similar to a RESTful web service (except being easier to code and much, much faster).
So... anyone able to answer the original question? If not, I'll dive in myself with thrift's included Cocoa support and see how it works on the iphone.
Just my two cents..
The accepted answer to this question, is an opinion to not use a technology, not an answer of whether it is possible.
Thrift, is an interface definition language, IDL, like Protobuf and Capt'n'Proto. They permit the definition of a client/server/server protocol which is platform agnostic. JSON and Plist don't provide the same level of type conformance.
Having previously lead an iOS team with 10Ms MAU using Google Protobuf v2.5 on iOS, Android, Windows, and server teams, I can attest that IDLs are great on mobile. Apple uses them for syncing iWork content.
My current team uses Thrift for iOS and Android clients, with a mostly Scala backend. I much prefer it to Protobuf.
We send Thrift payloads over HTTPS and WebSockets. Once you have defined (in Thrift) your our wire communication protocol (i.e. frame structure), it's very easy to evolve your APIs.
However, on iOS in particular there are some implementation issues. The current version of the library is quite poorly packaged, and if you hope to make an Objective-C framework (e.g. for iOS 8+), then you will not be able to out of the box with v0.9.2. This is because the library headers include local imports, (#import "TProtocol.h" instead of #import <Thrift/TProtocol.h>) with no umbrella headers. Worst of all, the Objective-C compiler generates very messy Objective-C classes, also including local imports from the Thrift library.
Some of these issues are pretty damning. It indicates to me that while use of an IDL is very much a good engineering decision, not many iOS teams are using Thrift, unless they're huge with the resources to write their own library.
I've always disliked frameworks that use a common interface definition that builds out both server and client code. It keeps both sides too much in lockstep where in reality server API changes must be very flexible in the versions of clients that are communicating with it.
There are helpful libraries that make JSON or PLIST communication over HTTP pretty easy, and decades of debugging and understanding the HTTP protocol and how to use it well. I would ignore that at your peril.
I have used thrift's objective c bindings for a large iPhone app with a few million users. As one of the posters mentioned we can use Http which gets the best of both worlds. However there is no asynchronous HTTP client for thrift. We had to build an event based wrapper to allow non-blocking I/O calls. The underlying layer still issues one call at a time which hit us in a big way because we have one server call that takes a long time but it does not block UI flow and another really fast one that does block UI flow. If the underlying layer is busy with the slow command our fast command just has to wait. I am trying to build asyc http in c++ which can then be used on the iPhone but that is someways off from being ready.
Thrift as an external API doesn't make sense. Use it internally rock and roll.