Showing posts with label client. Show all posts
Showing posts with label client. Show all posts
Tuesday, February 28, 2012
How to use the ElasticSearch Query DSL
I'm also in the process of developing an ElasticSearch Client based in Objective-C using RestKit, feel free to have a look & use it ... and shoot me an email if you want to contribute:
https://github.com/pulkitsinghal/ElasticSearchClient
Labels:
client,
DSL,
ElasticSearch,
ElasticSearchClient,
facet,
how,
JSON,
learn,
Lucene,
Obj C,
Obj-C,
Objective C,
Objective-C,
query,
range query,
restkit,
serialize,
Solr,
tutorial
Wednesday, February 22, 2012
CouchCocoa - An iOS client for working with CouchDB
CouchCocoa is a framework / library for iPhone use that abstracts out the work needed to talk to CouchDB instances running on the web or on the device itself.
If you want to jump right into the setup for a simple project, then simply follow these steps:
Aside from the process there are some "big picture" points to consider:
- Add CouchCocoa as a submodule to your project:
- cd ~/dev/myProject/
- git submodule add git://github.com/couchbaselabs/CouchCocoa.git
- Get all the dependencies of this submodule itself:
- cd ~/dev/myProject/CouchCocoa/
- git submodule update --init --recursive
- Drag & drop CouchCocoa's .xcodeproj file under your own project in Xcode
- Add the following as your target's dependencies so that they will get built:
- iOS Framework (CouchCocoa)
- iOS Library (CouchCocoa)
- Add the following in "Link Binary With Libraries" for your target:
- libCouchCocoa.a
- Add the following in "Header Search Paths" for your target:
- "$(SRCROOT)/CouchCocoa/Model"
- "$(SRCROOT)/CouchCocoa/REST"
- "$(SRCROOT)/CouchCocoa/Couch"
- "$(SRCROOT)/CouchCocoa/UI/iOS"
- In Xcode, select CouchCocoa.xcodeproj in the Project Navigator and edit the Target > Build Settings and set the Skip Install setting to Yes.
-
If at a later point of time you realize that you want to work with TouchDB as well then you *may* need to update your CouchCocoa submodule and bring it up to speed:
- cd ~/dev/myProject/CouchCocoa/
- git checkout touchdb
- git pull origin touchdb
Aside from the process there are some "big picture" points to consider:
- CouchCocoa can talk directly to CouchDB (or CouchBase - a more performant variant). For example, if you use the hosting services provided by IrisCouch, you can configure CouchCocoa to work directly with that Couch server.
-
CouchCocoa can work with an embedded version of CouchDB on mobile devices.
- TouchDB is one such implementation which is lightweight and exists for iOS and Android mobile devices.
- For iOS however, I do find it a bit confusing when I think about how to structure my project, there are two ways to do it:
-
Build and soft-link the TouchDB framework. And use CouchCocoa as a submodule as outlined earlier in the blog.
-
If you choose to use TouchDB-iOS as a submodule as well then don't forget that TouchDB's itself also needs a soft-link to CouchCocoa.framework:
cd ~/dev/superProject
ln -s ./DerivedData/superProject/Build/Products/Debug-ios-universal/CouchCocoa.framework ./TouchDB-iOS/Demo-iOS/Frameworks/CouchCocoa.framework
-
If you choose to use TouchDB-iOS as a submodule as well then don't forget that TouchDB's itself also needs a soft-link to CouchCocoa.framework:
- Syncpoint-iOS which bundles TouchDB and CouchCocoa together but lags behind the individual projects in terms of stability and features. To experiment with it, you can follow a this discussion thread where it was introduced to the community.
-
Build and soft-link the TouchDB framework. And use CouchCocoa as a submodule as outlined earlier in the blog.
- Another huge pain-point is the fact that for all of GitHub's glory it doesn't let me search for content in wiki pages so when it comes time to try out the infamous Grocery-Sync example, I'm left wondering where to look! This relative path should shed some light I hope: TouchDB-iOS/Demo-iOS/DemoAppDelegate.m
- For iOS however, I do find it a bit confusing when I think about how to structure my project, there are two ways to do it:
- Couchbase Mobile is another implementation. Recently it has seen some serious progress in terms of tutorials (one & two) and example-code covering its usage.
- TouchDB is one such implementation which is lightweight and exists for iOS and Android mobile devices.
Labels:
client,
CouchCocoa,
CouchDB,
iOS,
iPhone,
ObjC,
Objective C,
TouchDB
Friday, July 9, 2010
Flex Deep Linking and Server Side Redirects
With Flex its easy to:
a) use deep-linking (IBrowserManager & BrowserManager) to create application URLs that allow the use of the browser's backward & forward navigation buttons,
b) bookmarking a deep-linked URL and reloading it also works just fine
B U T ... what doesn't work is when you need to authenticate users before letting them access their bookmarked content. The reason behind this is simple ... the out-of-the-box javascript (history.js file) provided by the flex framework uses the # (pound/sharp) symbol to manage the deep link fragments. For ex:
1) http://www.hostname.com/application.swf#view=account
2) http://www.hostname.com/application.swf#view=profile
3) http://www.hostname.com/application.swf#edit=account
4) http://www.hostname.com/application.swf#edit=profile
Now according to the HTTP spec, the part after the # symbol is not sent over to the server in the HTTP request. This means that your server has no clue where to redirect the users after they successfully authenticate!
What can you do?
Workaround # 1:
1) Provide a bookmark button in the application itself and replace the # symbol with the ? symbol when storing the link.
2) Edit your client side to treat the ? symbol in the same way it treats the # symbol, therefore picking up the deep link fragments properly.
Workaround # 2:
1) Have your users manually edit their bookmarked links to replace the # symbol with the ? symbol.
2) Now that the deep link fragment is making it over to your server side as a URL parameter, edit your server side to replace the ? symbol with the # symbol when redirecting the user back to their bookmarked link. If you are using the spring-security framework then you can refer to the following blog as a reference on how to configure your application context's xml files properly.
a) use deep-linking (IBrowserManager & BrowserManager) to create application URLs that allow the use of the browser's backward & forward navigation buttons,
b) bookmarking a deep-linked URL and reloading it also works just fine
B U T ... what doesn't work is when you need to authenticate users before letting them access their bookmarked content. The reason behind this is simple ... the out-of-the-box javascript (history.js file) provided by the flex framework uses the # (pound/sharp) symbol to manage the deep link fragments. For ex:
1) http://www.hostname.com/application.swf#view=account
2) http://www.hostname.com/application.swf#view=profile
3) http://www.hostname.com/application.swf#edit=account
4) http://www.hostname.com/application.swf#edit=profile
Now according to the HTTP spec, the part after the # symbol is not sent over to the server in the HTTP request. This means that your server has no clue where to redirect the users after they successfully authenticate!
What can you do?
Workaround # 1:
1) Provide a bookmark button in the application itself and replace the # symbol with the ? symbol when storing the link.
2) Edit your client side to treat the ? symbol in the same way it treats the # symbol, therefore picking up the deep link fragments properly.
Workaround # 2:
1) Have your users manually edit their bookmarked links to replace the # symbol with the ? symbol.
2) Now that the deep link fragment is making it over to your server side as a URL parameter, edit your server side to replace the ? symbol with the # symbol when redirecting the user back to their bookmarked link. If you are using the spring-security framework then you can refer to the following blog as a reference on how to configure your application context's xml files properly.
Subscribe to:
Posts (Atom)