TextField Autocompletion with JSON Response - iphone

What I want :
I want to use Auto Completion of Text field in my App.As my data is coming from the web service, I want to perform the "Auto Completion" with the JSON Response.
What I Know :
I know that first I have to fetch data from the web service. Then I need to parse it and fill the Array with that parsed data and then I can use that array to perform Auto Completion.
Problem :
I don't know how to send the requests to get JSON data for each "prefix" that user types in text field (means I want JSON Data during Typing). I know how to perform "JSON Parsing" and "Auto completion of text fields" independently but no idea regarding "TextField Autocompletion with JSON Response". I tried a lot to find the answer regarding this but i failed. So Please Help me...
I am using the doautocompletetextfield to perform "Text field Auto completion".
Better Suggestion for this problem will be appreciated.
Any Solutions ?

You can use linear searching just like done in the api example or can use NSPredicate for fast searching in your autoCompleteArray.
According to your problem, you will get json data first, then you need to save relevant data from json into some array and then you can use this api to autocomplete the text in text field.
But i am confused about your this statement: "I don't know how to send the requests to get JSON data for each "prefix" that user types in text field."
1) Do you want to get json data from web service during typing?
2) Or you want to fetch data from json dictionary during typing?
If you want to go with option (1), i think it would be bad way to solve the problem.
And if you want to go with option (2) then you need to parse json and extract data of your interest and save it in an array. And then do autocomplete on the basis of the contents of that array.

Related

Automatically map contents of REST JSON body as flat table in Data Flow

With the Copy Data transformation it is possible to retrieve data from a REST call (array with flat json objects, similar to Odata) and copy the contents to a flat table keeping the data types from the source but without the necessity to set the schema for that specific data.
When I try to recreate this with Data Flow, I can't get this to work. When I check the Data Preview of my Source I get a hierarchy with a body (with my odata like data) and a header. And if I send that to my sink (Avro) it will be saved in this same hierarchical structure (including the header). I know I can fix this manually by using a Select operation (body.column1, body.column2, etc.), but I want to make my Data Flow dynamic so I'm able to use it with multiple tables/endpoints.
So I receive it like this with my REST source:
link
And I want it to be like this at my Sink without hardcoding my schema:
link
The only work around I can come up with is retrieving the data using Copy Data, put it somewhere temporarily and then use my data flow to further transform the data. Is there a more easy way to do this? I cannot imagine that I'm the only one that has this issue.
Hopefully it's clear and somebody is able to help. Thank you very much in advance.
Data flow projection will get schema from API including body and header. Hence, when you use auto mapping everything going to be saved.
Below work arounds you can think of,
As you mentioned, using copy data first and then data flow to further transform.
Use select or derived column transformations and transform your data to get all column names and then finally use sink. For this you can opt with Column pattern matching syntax. So that one condition can be meet with multiple columns to transform.
Check below link to know about column pattern mappings.
https://learn.microsoft.com/en-us/azure/data-factory/concepts-data-flow-column-pattern

DocuSign API: Is it possible to filter envelopes by the value a document field?

Assuming I have a field with label FOO in all the envelopes sent, how do I filter the envelopes where the value of FOO is 123456?
I tried setting the search_text parameter with 123456 but it doesn't work.
This is the request I tried to use:
https://demo.docusign.net/restapi/v2.1/accounts/reste_idreste/envelopes?from_date=2021-02-01&search_text=123456
Unfortunately, there's not currently a way to search Tabs/Form Data via the API. We do have long term plans in this area, but nothing firm yet. I would pass this request along to your account team to let them know you are interested in learning more about that functionality as it develops.
The ListStatusChanges call doesn't allow you to pull form data in bulk. You'd need to make one GetEnvelope call per envelope with include=recipients,tabs to pull form data and parse through it yourself.
If this is something you are looking at building out, you could use populate a local database using the GetEnvelope results, and then use DocuSign Connect to automatically pass information about new envelopes moving forward.
It is possible to search for values of Envelope Custom Fields. Moving forward, if your application can populate an ECF, you can then search for that to find specific envelopes.

Should I allow user-provided values to be passed through a query string?

I'm adding a search endpoint to a RESTful API. After reading this SO answer, I'd like the endpoint to be designed like:
GET /users?firstName=Otis&hobby=golf,rugby,hunting
That seems like a good idea so far. But the values that I'll be using to perform the search will be provided by the user via a standard HTML input field. I'll guard against malicious injections on the server-side, so that's not my concern. I'm more concerned about the user providing a value that causes the URL to exceed the max URL length of ~2000 characters.
I can do some max-length validation and add some user prompts, etc, but I'm wondering if there's a more standard way to handle this case.
I thought about providing the values in the request body using POST /users, but that endpoint is reserved for new user creation, so that's out.
Any thoughts? Thanks.
I see these possible solutions:
not actually a solution. Go with the query parameter and accept the length constraints
go with the POST solution that shouldn't be designed as you mention. As you point out, if you POST a user to .../users you will create a new user entity. But this is not what you want to do. You want to submit a search ticket to the server that will return a list of results matching your criteria. I'll design something as such
POST .../search/users passing in the body a representation of your search item
distribute the query both server side and client side. Say you have complex criteria to match. Set up a taxonomy of them so that the most strict ones are handled server side. Thus, the server is able to return a manageable list of items you can subsequently filter on the client side. In this approach you can save space in the query string by sending to the server only a subset of the criteria you want to meet in your search.

RESTful URI for Filtering Nested Collections

I'm looking for a good way to form a URI for a resource that filters on a collection of values contained within records. For example, say you have a recipe database and you want to search for recipes that contain "cherry" (obviously most recipes would contain multiple ingredients).
If I just want to filter on single values, I could do something similar to the following:
/recipe/search/?name=Spaghetti
But what about filtering on multiple values? I was considering something like the following:
/recipe/search/?ingredients=contains=cherry
Any thoughts on this? Is there a "standard" for a filter of this kind?
Update: One problem I have with my idea is the way it gets handled on the backend (in my case Rails). When querying the server with this particular format, Rails generates a Ruby hash that could get ugly like the following:
{"ingredients"=>"contains=cherry",
"action"=>"search",
"controller"=>"recipe"}
Your URI
First of all, in contrast to other answers I'll start from a REST perspective and then find appropriate additions to it. I am not strong in Ruby so bear with no-code on the backend.
Recipies are the entities you wanna present
your users find them at /recipies
HTTP has QUERYS for filtering
wanna have sorted those recipies by date? use /recipies/?sortby=date&sort=asc
Only recipies with cherries goes similarly: /recipies/?ingredients=cherry
So that's the REST way of structuring your basic URL.
For multiple matches there is no official way to do it, but i'd follow user1758003. This is an intuitive construction of the url and easily to parse on the backend, so we have /recipies/?ingredients=cherry,chocolate
Don't forget /recipies/search is not restful because it mirrors recipies and does not represent an independent entity. However it is a great place to host a searchform for visitors to your site.
Now there are some additional questions packed into the first, let me address them one by one:
I have a website consuming this api, how should the search form look like?
Give your visitors a /recipie/search page or a quick filtering possibility on /recipies.
Just set the <form action="/recipies" type="GET">. The browser will add all parameters as an Query string after /recipies.
Advanced functionality
A request to /recipies should list all. If you add a query every parameter of the query must be respected. so /recipies/?ingredients=cheese MUST only return cheesy recipies.
For multiply query parameter values there is no fixed standard but I'd like a service to be intuitive.
I read GET /recipies/?ingredients=cherry,chocolate as Get me the recipies which have ingredients of cherry and chocolate. To get a list of recipies containing either cherry or chocolate I'd want to write the URI like /recipies/?ingredients=cherry|chocolate which makes it visually very different from a comma and has a predefined meaning (OR) in programming contexts.
I'm not familiar with the specifics of ruby hashes but I'm guessing the hash is created to uniquely identified the query both at the http and data access levels?
Regardless, you want to be careful about URL encoding if you wish to use json in a query parameter. Another thing to keep in mind is the term "search" could be considered repetitive. If your server is being accessed using a GET method and you have criteria then hopefully you're not modifying any state in the back end. Not your question but just thought I'd mention it.
So...
https://yourserver.com/approot/recipe/search?ingredients=cherry,cheese&type=cake
HTTP doesn't define commas as a query string separator so your framework should be able to parse 2 query string parameters:
ingredients: "cherry,cheese"
which you should be able to easily covert to an an array using split or whichever equivalent function ruby provides.
and
type: "cake" (extra query term added to illustrate a point and because cherry cheese cake is awesome and cake is not an ingredient)
If I understand your example correctly you would end up with:
{
"ingredients"=>"cherry,cheese",
"type"=>"cake",
"action"=>"search",
"controller"=>"recipe"
}
Is this what you where looking for?
Most of the REST webservice using JSON data only.So use JSON format which will return single string value only. From this JSON format you can send the array value also.
For array value means you to convert that array into the JSON format like this
from php:
$ingredients = array('contains'=>array('fruits'=>'cherry,apple','vitamins'=>'a,d,e,k'));
$ingredients_json = json_encode($ingredients);
echo $ingredients_json;
it will return json format like this:
{"contains":{"fruits":"cherry,apple","vitamins":"a,d,e,k"}}
and you can use this JSON string in the url
/recipe/search/?ingredients={"contains":{"fruits":"cherry,apple","vitamins":"a,d,e,k"}}
in the server side we have the option to decode this JSON format value to the array.
{"ingredients"=>"{\"contains\":{\"fruits\":\"cherry,apple\",\"vitamins\":\"a,d,e,k\"}}",
"action"=>"search",
"controller"=>"recipe"}

Fetching data from webservice and caching on iphone

I want to access a webservice to fetch alot of data (e.g. product lists/details/search results) and display this.
Are there any best practices for this type of operations?
Performance-wise, is there any better way than retrieving, parsing and displaying text data on each request and maybe load images in the background? Are there any wise caching policies which may be applied?
If I were doing something like this from the ground-up, here's what I'd do:
Have the web site post all the data in XML. Except for maybe the pictures - just have an XML field specify a URL for each picture. So, for example, say I was doing a product list.
Use NSXMLParser to both fetch and parse the XML data.
Use a separate NSData dataWithContentsOfURL: call to fetch the contents of each image, with the URL from the XML data
Write the XML data, (and the NSData image) to a database table with CoreData. Add a indexed timestamp field to the table.
You can now use the timestamp field to keep the newest "x" records in the database - and can purge the older ones if/when you need to.
Use the contents of the database table to populate a UITableView - or however else you want to present.
Make some sort of "next", "prev" or "update" fields in the UITableView to get more data from the web, if you need to display more data than is what is cached - or you want to update the data in the cache.