I am using around 25 NSMutableDictionary in my singleton class to hold the data from web services. When I try to access those dictionaries if those dictionaries are nil, service will be invoked and dictionaries will be filled.
My questions are
When my app receives DidReceivedMemoryWarning, Will those dictionaries be released?
If it is not released, can i explicitly set those dictionaries to nil when app receives memory warning message?
Instead of doing step1 and step2, can i use NSCache instead of NSMutableDictionary as NSCache will be released automatically when app receives memory warning?
Related
I'm trying to read a sequence of JSON objects from a network stream. This involves finding complete JSON objects and returning them one by one. As soon as a complete JSON object was received, I need to have it. Anything else that follows that JSON object is for the next object and must only be used when the next complete object was received.
I would have thought that the Utf8JsonReader class could do that but apparently it cannot accept a Stream of any kind. It even seems to be unwanted to have that possibility.
Now I'm wondering if it's possible at all to use .NET's shiny new JSON parser to read from a stream when I don't know when data arrives and how much of it. Do I need to split the JSON object messages manually or can the already existing reader just stop when it has something and continue when the next thing is available? I mean, if it can do that on a predefined array of bytes, it could surely also do it with some waiting in between until more data is available. That just doesn't seem to be exposed in the public API. Or did I miss something?
The JsonDocument.ParseAsync(Stream) method cannot be used because it would read the stream to the end. That doesn't make sense for a network stream that stays open for a long time and just reads some data from time to time.
Working on developing rest endpoint, with spring-boot, to consume a resource from another microservice (external), since both the services are in development phases, there is quite a lot of changes in request and response frequently. Many times our micro-service failed because of change in response from the target microservice.
To avoid this failure, we thought of Defining a JSON schema in the calling client to describe the expected response.
If there is a schema mismatch log an error message, prefixed with "JSON_SCHEMA_MISMATCH".
Please advise if there are any other better solutions for handling this in a more generic way, meaning the same could be used for other microservices as well without more duplicated codes.
You can use objects to directly fetch the values from the services.
For example -
VOClass vOobject = restTemplate.getForObject(url, VOClass.class, params);
The microservice which you are using should also return the same object, or the json with same variable names.
If there are variables you are getting in response match the variables from your VOClass object then those values will be set and those not matching will be null.
ALso if there are new varaibles returned from microservice, you can cosume them by adding those variables in your VOClass.
Could you please explain Square's Retrofit response parsing logic.
I'm interested in case when we should receive & parse a big json (>100Kb) - will Retrofit wait while all content will be received from server and only than parse it, or it will start to parse it immediately while getting stream data?
My goal is to speedup response processing.
Are there any options about it available to configure?
As soon as the HTTP client parses the headers, the InputStream will be handed back to Retrofit which will then hand it directly to the Converter. This means that as the underlying converter mechanism (say, Gson) is pulling bytes they are being read (and potentially blocking) directly from the network.
Note: this is only true if logging is off (as it should be in production / release builds). When logging is turned on beyond HEADERS level, the response body has to be read in its entirety into a byte[] in order to both log and hand the data to the converter.
I am working on a TCP-based proxy that must first do a REQ/REPLY handshake in json on a given connection. Because JSON is a self-delimiting protocol I reach for Go's json.Decoder to pull off this work which does the job nicely.
Here are the steps I take:
Dial a connection to a remote server
Write a single json request to a remote server (REQ)
Read a single json reply from the same remote server (completing the proxy handshake REPLY)
Upon a valid json handshake, pass the client connection onto another part of the code which will (going forward) switch to a text based protocol from this point on.
The problem is, when json.Decoder reads data into its internal buffer it can potentially read more data than it needs in which case the json.Decoder has a Buffered() method which gives back an io.Reader with the remainder of the data.
This data (available in the Buffered() method) is now the text-based protocol data which needs to get read from the connection after the json hand-shake did its work. But if I pass the connection forward as is without considering the left over buffer, the connection gets into a locked state because it is waiting to read this data which never comes. The code that deals with the text-based protocol expects a net.Conn going forward and once I pass the connection forward (after the json handshake has been made) the code utilizing the connection understands how to speak the text-based protocol at this point on. So there should be a clear boundary of work.
My question is what is the ideal way to solve this issue so I can still take advantage of the json.Decoder, but ensure that when I pass the connection to a different part of the code in my proxy I know the start of the data for the text-based protocol will still be readable. I somehow need to take the remaining data in the json.Decoder's Buffered() method and put that back in front of the connection so it can be properly read going forward.
Any insight is much appreciated.
You can try
type ConnWithBuffIncluded struct{ //Implement net.Conn so can be passed through pipeline
net.Conn
json.Decoder
}
func (x ConnWithBuffIncluded) Read(p []byte) (n int, err error){ //Will Read both sources
return io.MultiReader(x.Decoder.Buffered(), x.Conn).Read(p)
}
The company I'm working at is considering using RestKit. However, the JSON that our server returns is surrounded characters for security reasons. It's a pain. In another iPhone app, one that does not use RestKit and uses JSON only very little, I parse the string returned from the server, removing the characters preceding and trailing the JSON string. Once the the string is parsed, I call JSONValue on the string (we're using SBJSON) and get an NSDictionary.
I've heard that RestKit features a pluggable architecture. If that's the case is there somewhere I can intercept the strings coming back from the server prior to the point where RestKit does its parsing?
I wanted to find a fix that did not require me to change the RestKit codebase in any way and I found it. The answer was to create and register my own parser.
Parsers need to conform to the RKParser protocol. Basically what I needed to do was trim the server response and not parse the response into objects - there was already a parser that did that: RKJSONParserJSONKit. So I subclassed this class and registered my parser at start up:
[[RKParserRegistry sharedRegistry] setParserClass:[MyJSONParser class]
forMIMEType:#"application/json"];
Just wanted to note that nowadays you can implement your own retrieve/map operation by subclassing the
RKHTTPRequestOperation (doc) — for retrieving file from server
RKObjectRequestOperation (doc) — for mapping
RKManagedObjectRequestOperation (doc) — for mapping to core data objects
and registering them with [RKObjectManager registerRequestOperationClass:] (doc) method.