I use an NSXMLParser to parse ext. API data. I also use a Singleton shared array var to maintain info retrieved from ext API.
This info is dynamic and changesas the user types anything in UISearchBar
Now the thing is as soon as the user types anything, I clear off the existing array contents by using [retrievedArray removeAllObjects];
Thus this refreshed retrievedArray based on the current terms in the search bar.
This works fine if the user types slowly. However I get to see duplicate search results if the user types very fast. This, I am assuming, is because the retrievedArray contents do not get enough time to clear off.
I am still trying to resolve the issue. Please suggest some more fixes.
Could you please provide me the fix.
No, I don't think this is the case, unless you're doing search in a separate thread and clear array in another one. If not, then there is probably error in your search logic.
First of all I think a singleton approach may not be the best way to go for what you are doing. But make sure that you are synchronizing all mutable access to the array. Instead of allowing the singleton to return a NSMutableArray for any object and their mom (super) to use you need to have methods like addObject,removeObject,clear with #synchronize blocks or any kind of lock you decide on. I still see issues with this approach because the code calling addObject, remove and clear will all need to be synchronized as well. Maybe consider on each auto complete request you use a delegate or post a NSNotification containing a timestamp, the characters the user typed to get data, and a NSArray of results. At that time you can see if the response is still valid, discard any invalid responses, and update the user with just the contents of the most recent valid NSArray
Related
I will need to create a Custom Button "convert lead" that will perform the same functionality as Standard Button "Convert" when the button is clicked.
What is the best approach to do it..?
That's a very broad question. What exactly you need, what have you tried so far? Do you really need just a button that opens the conversion page or something more?
If you want to somehow recreate it with Apex... Core of the coded solution would be the Database.convertLead method. You don't pass to it whole leads (like to Database.insert for example) but instead just their IDs + bunch of control flags to make it do exactly what you need. Read up about LeadConvert object. And similarly you can get Account/Contact/Opportunity ID from the result object if it succeeded.
I don't think there's programmatic way to access field names & mappings defined by administrator for lead conversion. Maybe you'd need to store this info somehow (in helper object? custom metadata?). So then you'd query the field names from metadata, then query the lead fields and finally display table of fields & mappings to the user.
As the document says, MediaResponse contains mediaObjects property, and mediaObjects is array of mediaObject, but when I tried to put multiple mediaObjects, I got this error:
MalformedResponse at
expected_inputs[0].input_prompt.rich_initial_prompt.items1.media_response:
Only 1 media_object is allowed. First media_object will be used while
rest will be filtered.
Then what is the point of having an array of mediaObject?
There are several places in the protocol that contain an array where only one object is permitted in the array. One assumes that the designers wanted to make it expandable in the future without having to add special casing.
In this case, it sorta makes sense - right now we can only send one media object as part of the reply. It might be reasonable that, in the future, we could send one or more without having to come back to our webhook.
From this article Understanding Lift's RequestVar, I know that the data inside RequestVar actually stored in global map, and the value is visited by name.
So when the form doesn't pass validation, we can still get the value inside the RequestVar because the new RequestVar object we initialized has the same name as previous one.
It seems that the value is stay in the global map, and won't be cleared? We will not use it but we don't clear it? If it will be cleared, when it will be done?
If not, is it possible to visit the value of previous request?
So when the form doesn't pass validation
what form are you talking about? I'll presume that you think just of any data stored in RequestVar.
If it will be cleared, when it will be done?
The requestVar is cleaned after the request ends. Checkout the detailed wiki page: https://www.assembla.com/spaces/liftweb/wiki/Managing_State
I don't want to copy-paste from there to avoid outdated data in the future.
If not, is it possible to visit the value of previous request?
It's not possible using a RequestVar, you should use a SessionVar instead. The info about it can be found on the same link I posted.
I've implemented CRUD functionality pretty restfully in my WebAPI project. I'm now trying to implement Archiving of objects (not quite deleting) - if only there were an ARCHIVE HTTP method.
I see two options:
1) Have isArchived as a property of every archive-able entity, which must be included in PUT and POST requests even if archiving isn't relevant to the request. Archiving an entity would be a matter of calling PUT /api/object/id with isArchived set to true. Seems bulky on the wire but restful.
2) Have an RPC-ish url like PUT /api/object/id/archive that doesn't require a body. Seems the most efficient but not restful.
What's everyone doing in the "archive my stuff via an api call" space?
This is an excellent question, but I suspect it may eventually be marked as opinionated because I don't see a correct answer... as the OP also stated.
I would recommend treating the archive as a separate object store (or, even, different object types), if that makes sense for your system. Object design should not depend upon how the DB persists your data.
Thus, this is the most RESTful design I can come up with right now (assuming archiving and updating are always separate actions -- which they should be):
Typical (everybody knows this):
GET /api/object get all current objects
POST /api/object new current object
PUT /api/object/id update current object
DELETE /api/object/id delete current object
GET /api/object/id get current object
The weirdness:
POST /api/object/id/archive move object to archive (makes some REST sense)
POST /api/object/id move object from archive (muddy)
The archive:
GET /api/object/archive get all archive objects
PUT /api/object/id/archive update archive object (if possible)
DELETE /api/object/id/archive delete archive object (tempting for unarchive)
GET /api/object/id/archive get archive object
Or, maybe one of these mods for archive URLs:
GET /api/object/archive/id get archive object
GET /api/objectarchive/id get archive object
But......
The above feels pretty muddy (not very self-documenting) for moving objects in and out of the archive. It also leads to some REST API design pain where update/delete/get of an archived object probably don't need archive-specific functions. Thus, I ultimately settled on this:
GET /api/object get all objects
GET /api/object?archived=false get all current objects
GET /api/object?archived=true get all archive objects
POST /api/object new current object, returns all current objects*
PUT /api/object/id update object (current or archived; cannot change archive state)
DELETE /api/object/id delete object (current or archived), returns objects of same archive state as deleted*
GET /api/object/id get object (current or archived)*
PUT /api/object/id/archive body:{archived:true} move object to archive, returns all current objects*
PUT /api/object/id/archive body:{archived:false} move object from archive, returns all archive objects*
* Return could be expanded/overridden with a query string if design calls for it.
Admittedly, this is mostly a reversal from my earlier statement of treating the archive as a separate object store. Yet, that thought process is what ultimately led to this compromise in design. This feels good to me on most fronts.
I, personally, don't agree with using the query string for anything but... uh... queries. So, I don't. Payload for data changes -- no matter how small -- should go in the body (when it doesn't fit with a REST verb and URL, that is).
If you always archive a particular resource and never delete it, I would repurpose DELETE to actually archive. If you really need to differentiate between delete and archive, I would either do
GET /foo/33
200 OK
<foo id="33">blah</foo>
POST /archive
<foo id="33">blah</foo>
201 Created
Location: http://example.org/archive/foo/33
or just
POST /archive?target=http://example.org/foo/33
201 Created
Location: http://example.org/archive/foo/33
I'd use the /api/object/id?archive=true approach.
But, as to whether you should use PUT or POST depends. If you use PUT, any subsequent calls to the same URL would not change anything about the resource. If you use POST, the implementer expects that any subsequent calls to that URL will indeed change the state. (Don't ask me how, I'm assuming that you will use the PUT verb on this one.)
This is due to the fact that PUT operations should be idempotent. See section 9.1.2 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
I would probably use the /api/object/id endpoint with a query parameter, so it looks something like /api/object/id?isArchived=true. You can still use whatever HTTP verb you were using.
The NSString object that is got by the following code has got a retainCount of 95.
for(GDataXMLElement *ele in [doc.rootElement elementsForName:#"myKey"])
{
NSLog(#"myKey %d",[[[ele.children objectAtIndex:0] stringValue] retainCount]);
[myDict setObject:[[ele.children objectAtIndex:0] stringValue] forKey:#"myKey"];
}
. so would it get released later when
[myDict removeAllObjects];
[myDict release];
is called.
the problem i am facing is that i have hundreds of strings like this parsed.... and all their retaincounts are around 95...would these strings get released?
the problem i am facing is that i have hundreds of strings like this
parsed.... and all their retaincounts are around 95...would these
strings get released?
First, retainCount is useless. Don't call it. No, really, don't use retainCount.
To answer your question, look to Instruments. Do the objects that you expect to go away actually stay in memory? If so, then turn on reference count tracking and see what still holds references to them (or what retains are unbalanced).
More likely than not, the XML subsystem is unique-ifying the strings such that only one copy of what may be repeated hundreds of times is in memory. That one copy may be retained dozens or hundreds of times as a result. When you removeAllObjects from myDict, there may still be a reference to the objects. It might even be an autoreleased reference and, thus, will actually go away.
The only way to know is to look to see if the objects are deallocated via Instruments (or some other means).
As per the definitions & explanations given by many others including raywinderlich in his How To Choose The Best XML Parser for Your iPhone Project.
GDataXML is nothing but a NSXML style DOM XML parser for the iPhone, developed by Google as part of their Objective-C client library. Consisting of just a M file and a header, it supports both reading and writing XML documents and XPath queries.
A DOM parser reads the entire document and builds up an in-memory representation that you can query for different elements. Often, you can even construct XPath queries to pull out particular pieces.
So it just creates a tree like structure for the given entire XML, each elements can be queried to pull particular pieces.
And as we know this all works with the pointers, so what ever elements we get from this tree will be just pointing to that object, with the same name(used while initializing xml) or a new name while pulling particular pieces(using NSXMLElement).
And so everything will be retained until we release the XMLDoc while initializing XML.
If you want we can check the retain counts after releasing the XMLDoc(but it may give crash as are we using released object).
I think it works in this way, if you or other developers have any other info on this share your info.