Should I use traditional .NET methods or the MonoTouch .NET wrapper (1-1 mapping)?
Rephrase: Should I use .NET´s e.g WebClient object or NSURLRequest (in .NET)?
I can think of many situations where you have to choose between .NET and .NETified objective-c.
Is there a rule of thumb here? Because I don´t think it´s obvious.
BR
You should probably also have a look at ServiceStack.
I can't really offer a fully balanced answer, however you may be interested to know that we've been using .NETs methods from an iphone to great success.
Related
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 have been using ASIHTTPRequest for quite a while now and i quite satisfied with it. However since it has been deprecated, I am considering replacing it. My first though was to go with the NSURLConnection, but I found out that ASIHTTPRequest actually does quite a lot. For example I like its queue handling.
The iPhone application that I am working on uses a REST API, so I have been considering RESTKit. Is is possible to use RESTKit without Core Data? As it is know I have pure dataobjects and I do not want to use Core Data, not right now anyway.
Are there any other good alternatives to ASIHTTPRequest?
BTW I know that there is a similar question but this is more specific.
I think that AFNetworking is a good solution.
Pros:
Small
Well documented
Simple to install, only copy the source code into your project.
Simple to use.
An excellent category for UIImageView for loading icons in the background.
Cons:
No way of setting the timeout for requests. (Applies to v0.9.0)
I can definitely recommend RestKit, I make use of it a lot! It handles common stuff for you and no, you don't have to use Core Data. RestKit can work with it, but that is just a nice feature.
A good starting point for using RestKit is the wiki on github.
RestKit relies on AFNetworking as a networking framework. If RestKit seems to be an overkill, you may want to try only this one.
Try the BYRequest:
BYRequest based on MKNetowrkKit, but it works like ASIHttpRequest, so you can easily migrate your project from ASIHttpRequest to BYRequest and also enjoy ARC.
https://github.com/BoydYang/BYRequest
Does it make sense to use Play just for making the main layout, and use GWT-compoments (like # {some_gwt_component}) if it's needed (for example to implelemnt this component with jquery/javascript/html is quite complicated)?
Why I'm asking, because, it seems, some thinks easy to implement just with html some with gwt.
I can't think that it's a good idea to mix this techniques. Has you seen the post on google-groups? It refers to information about play and gwt.
I wouldn't recomend it, GWT relies in the Servlet model (as far as I remember, I may be wrong) and that doesn't mix well with Play.
Also, on a more personal level, I know GWT is not really recommended by Thoughtworks as a technology (they list several issues with it) and given the technological knowledge of those guys, I usually trust their recommendations. Stay away from GWT :)
I know already:
Core Data, SQLite3, Property List Serialization, NSCoding with NSCoder (encode / decode)... what else?
Another framework is BNRPersistence, which uses Tokyo Cabinet (I haven't tried it, so I don't know how good it is). Other than that, you can do pretty much anything you want--JSON or custom XML come to mind, but you can also use pretty much any C-based library.
You listed the standard ones. Of course you've got access to a file system, so you can pretty much do anything. What are you looking for?
I'm faced with writing a framework to simplify working with a large and complex object library (ArcObjects). What guidelines would you suggest for creating a framework of this kind? Are static methods preferred? How do you handle things like logging? How do you future proof your framework code from changes that a vendor might introduce?
I think of all of the various wrappers and helpers I've seen for NHibernate, log4net, and code I've read from projects like NLog and NetTopologySuite and I see so many good approaches, but honestly I'm at a loss where to start.
BTW - I'm working in C# 3.5 but it's more about recommended approach rather than language.
Brad Abrams' Framework Design Guidelines book is all about this. Might be worth a look.
Try to write code to be more flexible. For example, if you have a method that accepts an array as a parameter, would you be able to accept an IEnumerable or IList instead?
I think that you're consistent is more important than what conventions you go with. As far as future-proofing yourself, that's a matter of the code that you're making a framework for. It's a lot easier to build on a brick house than a sand one.
Writing code for framework is absolutely very different from writing application code.
I have always consulted (and have others consult) the Design Guidelines for Class Library Developers when writing framework level code.