One of the fallouts from the new encrypted storage API we added last week is the fact that it encrypts things like preferences making them unusable if you expected them to work before/after encryption was applied. To workaround this we added a new API to the
public static void setPreferencesLocation(String storageFileName)
public static String getPreferencesLocation()
These API’s allow us to determine the storage file in which the preferences are stored (not to be confused with
FileSystemStorage file). By default preferences are stored in
CN1Preferences but you can use any file name you want. This is useful if your app allows several logins and you might want to use preferences differently for every login.
A while back a user contributed a change the triggered the simulator location dialog popup automatically when working with the location API. This seemed like a good idea at the time but proved to be one of the most annoying features if you have things like background location tracking.
So until we have a configuration to enable/disable it by default we decided to turn this off. You can still open the location popup from the simulator menu if you want it.
We recently ran into a weird misbehavior in the Amazon AWS API where they relied on the order of the post values and would fail if they weren’t delivered in a specific order within the body of the request.
Unfortunately, we used a
Map to store the elements and the elements in Java maps are ordered based on their
hashCode() method value which doesn’t comply to the key/value order. With the next update we’ll replace the internal
LinkedHashMap which preserves the addition order and that way
addArgument will determine the order in which the element appears in the URL/body of a request.
This actually has some merit. With an upload Amazon can evaluate values of small fields before the full file is uploaded to S3. That way it can reject something quickly before the server/network or device do the actual upload.